4 ms·

Free SSL.. for all paid dynos. Apparently, if you're developing an application, you are expected to be okay with having your stuff MITMed. Yes, this is me bein

Free SSL.. for all paid dynos. Apparently, if you're developing an application, you are expected to be okay with having your stuff MITMed. Yes, this is me being excessively negative. Not having SSL-by-default in 2017 is excessively stupid. The certs are free, the system fully automated from both sides. Why hold back? There is no excuse for not having it system wide. Unencrypted HTTP needs to start being treated as the danger it is.

michaelper22 10y ago
Free dynos with a ____.herokuapp.com domain have SSL enabled by default, at no cost (under their wildcard certificate?). Seems the only missing case is when using a custom domain with a free dyno.
- Karunamon 10y ago
  It's an obvious missing case, and one that they are clearly conscious of given the constant insertion of the word "paid" in front of "dyno" throughout this announcement post. The mentality of holding out SSL as a paid addon needs to end. It needed to end years ago. It had no excuse to not end the moment LetsEncrypt went live.
  - mattzito 10y ago
    Implementing support for LetsEncrypt SSL does have a cost associated with it, particularly at scale. I think restricting the feature to paid users is totally reasonable, particularly since it's still vastly cheaper than getting a traditional SSL certificate.
    - Karunamon 10y ago
      And what exactly would that cost be? Can it even be quantified? We're speaking of a 4x yearly ACME request of a few kilobytes going to and from the LE servers. It certainly isn't bandwidth. The engineering work was already done, and doesn't change based on the number of instances that are making the cert request. It certainly isn't labor. It certainly isn't storage. Certs are 2-4 kilobytes. Even if we assume Heroku has 5M active dynos and each one has its own unique cert, that's only 20 gigabytes worth of certs, which is miniscule. So where's the cost coming from? Answer: It isn't. This is just tier differentiation, not cost recovery.
      - travisby 10y ago
        > The engineering work was already done, and doesn't change based on the number of instances that are making the cert request. It certainly isn't labor. And what pays for that engineering work? The money you make from having the feature.
      - mattzito 10y ago
        Oh my - so, it's actually a lot more complicated than that. Let me run it through for you: - You have to build enough of a retry algorithm so that you start renewing well in advance of the expiration date. - You then have to build the mechanism for warning customers that there was an issue renewing for one of a variety of reasons - You then have to deal with situations where LE has issues, which happens fairly often - There's a queueing system, where you have to handle not sending too many certs at once - You will end up in scenarios where users will migrate off of you, not tell you, attempt to issue another LE cert with another service, and fail, and then blame you - Similarly, you will have users who connect and disconnect domains, and your system has to be smart enough to properly revoke certificates without locking out a domain from too many retries - and then what happens when you can't renew a cert for whatever reason? Do you break the user's site? Do you fall back to http? I'm not saying it's millions of dollars, but at scale, it's complicated. Here's a blog post about how Squarespace did this (disclosure, I work there): https://engineering.squarespace.com/blog/2016/implementing-ssl-tls-for-all-squarespace-sites https://engineering.squarespace.com/blog/2016/implementing-s... Saying it's "just" a 4x acme request annually demonstrates a real lack of understanding of supporting this kind of system at scale.
        Karunamon 10y ago
        I didn't say that it was easy. I enumerated three things that it can't be. Given that Heroku is already generating certs on the fly for the (randomly named) dynos, offering that is even more engineering work than just sending a cert request for a custom domain, the numbers of which will be significantly smaller. [DISREGARD THIS - no they're not. Those are all on a single wildcard] My whole gist here is that every conceivable practical excuse I can think of for not extending that feature out to custom domains resolves as a nonissue, which only leaves feature differentiation to drive sales as the remaining option. Which, as mentioned before, is a legitimate business tactic, but morally evil in the security climate of 201x+.
JoshGlazebrook 10y ago
Or you can just make use of https://<dyno-name>.herokuapp.com https://<dyno-name>.herokuapp.com
mynameisvlad 10y ago
You can always get the certificate yourself and then upload it to Heroku. You own the custom domain, so you can use dns-01 instead of http-01 verification. Or, as others mentioned, the default endpoint is SSL-enabled.
- Karunamon 10y ago
  That's just the problem, though. The level of labor for Heroku enabling for everyone is negligible, and holding out on basic security as a paid addon in 2017 is just plain reprehensible. HTTPS should be the bare minimum for all connections in 2017, with HTTP fallback if requested. That should be the paid add-on. I really don't see how this is such an unreasonable sentiment that it deserves maximum downvotes.
  - sanswork 10y ago
    As others have said though they aren't holding out on basic security. They are holding out on custom domains with security. They provide SSL for free if you don't use a custom domain. It's unreasonable because they provide what you are asking for at a free price point and you're complaining "Not enough!".
    - Karunamon 10y ago
      You're right. Holes in basic SSL stuff, custom domain or otherwise, leading to insecure defaults are "not enough". People need to really start demanding more from their hosting providers. Then again, this is the Heroku that sent Rap Genius on a months long troubleshooting spree and tens of thousands in expense due to poor documentation, so perhaps I should just mentally file them in the same bucket as Godaddy and be done with it.
      - sanswork 10y ago
        Given your apparent unwillingness to pay for any of their services anyhow I'm guessing this mental filing will only serve to save them money.
kevindong 10y ago
They are offering SSL free to all free dynos under the https://<foo>.herokuapp.com https://<foo>.herokuapp.com domain. If they offered free SSL for custom domains too, what's the incentive to upgrade to a paid dyno for applications that don't require a large amount of resources? To be fair to Heroku, they have the right to make a profit. As is, it's amazing that they offer a fully free tier. If you don't like their policies, you are free to not use their services.
- Karunamon 10y ago
  If they offered free SSL for custom domains too, what's the incentive to upgrade to a paid dyno for applications that don't require a large amount of resources? This is exactly my point. The fact that companies are still bucketing "SSL" into "things we can charge extra for" rather than "things that should be the absolute minimum we provide" is irresponsible. Plaintext on the public internet needs to go away in whole.
  - kevindong 10y ago
    You do have a point. In fact, philosophically, you are correct. You are correct in the same way that the National Association of the Deaf was correct in filing a complain against UC Berkeley to make all of their publicly accessible course materials accessible (Berkeley, rather than captioning all of their materials, instead decided to take down all of their materials) [0]. But here's the thing: they are providing SSL for free for non-custom domains. Everything you can do with a custom domain can be done on the <foo>.herokuapp.com subdomain. You are intentionally choosing to use a custom domain. They define that as a feature worth charging for. No one is saying you must MITM your own application using something like Cloudflare. No one is saying you must use a custom domain. No one is saying you can't use the <foo>.herokuapp.com subdomain. Heroku is not a non-profit/government organization. They are not under the obligation to advance the public good. In fact, as a publicly traded company (as a subsidiary of Salesforce), they're actually obligated to maximize revenues and profits. [0]: https://www.washingtonpost.com/local/education/why-uc-berkeley-is-restricting-access-to-thousands-of-online-lecture-videos/2017/03/15/074e382a-08c0-11e7-a15f-a58d4a988474_story.html https://www.washingtonpost.com/local/education/why-uc-berkel...

michaelper22 10y ago

Free dynos with a ____.herokuapp.com domain have SSL enabled by default, at no cost (under their wildcard certificate?). Seems the only missing case is when using a custom domain with a free dyno.

Karunamon 10y ago
It's an obvious missing case, and one that they are clearly conscious of given the constant insertion of the word "paid" in front of "dyno" throughout this announcement post. The mentality of holding out SSL as a paid addon needs to end. It needed to end years ago. It had no excuse to not end the moment LetsEncrypt went live.
- mattzito 10y ago
  Implementing support for LetsEncrypt SSL does have a cost associated with it, particularly at scale. I think restricting the feature to paid users is totally reasonable, particularly since it's still vastly cheaper than getting a traditional SSL certificate.
  - Karunamon 10y ago
    And what exactly would that cost be? Can it even be quantified? We're speaking of a 4x yearly ACME request of a few kilobytes going to and from the LE servers. It certainly isn't bandwidth. The engineering work was already done, and doesn't change based on the number of instances that are making the cert request. It certainly isn't labor. It certainly isn't storage. Certs are 2-4 kilobytes. Even if we assume Heroku has 5M active dynos and each one has its own unique cert, that's only 20 gigabytes worth of certs, which is miniscule. So where's the cost coming from? Answer: It isn't. This is just tier differentiation, not cost recovery.
    - travisby 10y ago
      > The engineering work was already done, and doesn't change based on the number of instances that are making the cert request. It certainly isn't labor. And what pays for that engineering work? The money you make from having the feature.
    - mattzito 10y ago
      Oh my - so, it's actually a lot more complicated than that. Let me run it through for you: - You have to build enough of a retry algorithm so that you start renewing well in advance of the expiration date. - You then have to build the mechanism for warning customers that there was an issue renewing for one of a variety of reasons - You then have to deal with situations where LE has issues, which happens fairly often - There's a queueing system, where you have to handle not sending too many certs at once - You will end up in scenarios where users will migrate off of you, not tell you, attempt to issue another LE cert with another service, and fail, and then blame you - Similarly, you will have users who connect and disconnect domains, and your system has to be smart enough to properly revoke certificates without locking out a domain from too many retries - and then what happens when you can't renew a cert for whatever reason? Do you break the user's site? Do you fall back to http? I'm not saying it's millions of dollars, but at scale, it's complicated. Here's a blog post about how Squarespace did this (disclosure, I work there): https://engineering.squarespace.com/blog/2016/implementing-ssl-tls-for-all-squarespace-sites https://engineering.squarespace.com/blog/2016/implementing-s... Saying it's "just" a 4x acme request annually demonstrates a real lack of understanding of supporting this kind of system at scale.
      - Karunamon 10y ago
        I didn't say that it was easy. I enumerated three things that it can't be. Given that Heroku is already generating certs on the fly for the (randomly named) dynos, offering that is even more engineering work than just sending a cert request for a custom domain, the numbers of which will be significantly smaller. [DISREGARD THIS - no they're not. Those are all on a single wildcard] My whole gist here is that every conceivable practical excuse I can think of for not extending that feature out to custom domains resolves as a nonissue, which only leaves feature differentiation to drive sales as the remaining option. Which, as mentioned before, is a legitimate business tactic, but morally evil in the security climate of 201x+.

JoshGlazebrook 10y ago

Or you can just make use of https://<dyno-name>.herokuapp.com https://<dyno-name>.herokuapp.com

mynameisvlad 10y ago

You can always get the certificate yourself and then upload it to Heroku. You own the custom domain, so you can use dns-01 instead of http-01 verification. Or, as others mentioned, the default endpoint is SSL-enabled.

Karunamon 10y ago
That's just the problem, though. The level of labor for Heroku enabling for everyone is negligible, and holding out on basic security as a paid addon in 2017 is just plain reprehensible. HTTPS should be the bare minimum for all connections in 2017, with HTTP fallback if requested. That should be the paid add-on. I really don't see how this is such an unreasonable sentiment that it deserves maximum downvotes.
- sanswork 10y ago
  As others have said though they aren't holding out on basic security. They are holding out on custom domains with security. They provide SSL for free if you don't use a custom domain. It's unreasonable because they provide what you are asking for at a free price point and you're complaining "Not enough!".
  - Karunamon 10y ago
    You're right. Holes in basic SSL stuff, custom domain or otherwise, leading to insecure defaults are "not enough". People need to really start demanding more from their hosting providers. Then again, this is the Heroku that sent Rap Genius on a months long troubleshooting spree and tens of thousands in expense due to poor documentation, so perhaps I should just mentally file them in the same bucket as Godaddy and be done with it.
    - sanswork 10y ago
      Given your apparent unwillingness to pay for any of their services anyhow I'm guessing this mental filing will only serve to save them money.

kevindong 10y ago

They are offering SSL free to all free dynos under the https://<foo>.herokuapp.com https://<foo>.herokuapp.com domain. If they offered free SSL for custom domains too, what's the incentive to upgrade to a paid dyno for applications that don't require a large amount of resources? To be fair to Heroku, they have the right to make a profit. As is, it's amazing that they offer a fully free tier. If you don't like their policies, you are free to not use their services.

Karunamon 10y ago
If they offered free SSL for custom domains too, what's the incentive to upgrade to a paid dyno for applications that don't require a large amount of resources? This is exactly my point. The fact that companies are still bucketing "SSL" into "things we can charge extra for" rather than "things that should be the absolute minimum we provide" is irresponsible. Plaintext on the public internet needs to go away in whole.
- kevindong 10y ago
  You do have a point. In fact, philosophically, you are correct. You are correct in the same way that the National Association of the Deaf was correct in filing a complain against UC Berkeley to make all of their publicly accessible course materials accessible (Berkeley, rather than captioning all of their materials, instead decided to take down all of their materials) [0]. But here's the thing: they are providing SSL for free for non-custom domains. Everything you can do with a custom domain can be done on the <foo>.herokuapp.com subdomain. You are intentionally choosing to use a custom domain. They define that as a feature worth charging for. No one is saying you must MITM your own application using something like Cloudflare. No one is saying you must use a custom domain. No one is saying you can't use the <foo>.herokuapp.com subdomain. Heroku is not a non-profit/government organization. They are not under the obligation to advance the public good. In fact, as a publicly traded company (as a subsidiary of Salesforce), they're actually obligated to maximize revenues and profits. [0]: https://www.washingtonpost.com/local/education/why-uc-berkeley-is-restricting-access-to-thousands-of-online-lecture-videos/2017/03/15/074e382a-08c0-11e7-a15f-a58d4a988474_story.html https://www.washingtonpost.com/local/education/why-uc-berkel...