Announcing Free and Automated SSL Certs
blog.heroku.com
blog.heroku.com
I hope the other PaaS will follow.
(I'm CEO there)
If your company does hosting - your company should provide TLS certs via Let's Encrypt automatically.
[0] Can we start dropping the SSL part now? Generally SSL v2/v3 is disabled so it is all over TLS anyway.
It's the same certificate though. So can we start calling them X.509 certs which is more proper than SSL or TLS cert?
Correction: As part of the paid plan.
Why give for free sometimes you can charge money for.
I only just now noticed a rather serious typo there, making that sentence confusing. Should have said "the only reason TLS should be a paid feature", which fits with the rest of the sentence.
So really they are charging you if you need a custom domain and security (i.e. Something most businesses do need and most hobbies don't).
Seems a like a reasonable and fair way to segment their market to me.
Many kinds of static content need TLS, including protection from MITM and protection from eavesdroppers. Static doesn't mean "not sensitive". (Leaving aside the reasonable presumption today that all content is potentially sensitive.)
>Hosting a static free blog doesn't need TLS.
Completely wrong, although others explained why already.
Which somehow changes its meaning .
And also greatly reduces the need since you can simply give every site/service a unique certificate instead of sharing a cert throughout all your deployments.
Not free. Included with purchase.
That's the announcement.
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.
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.
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.
- 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-s...
Saying it's "just" a 4x acme request annually demonstrates a real lack of understanding of supporting this kind of system at scale.
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+.
-bash-4.1$ curl -vkLs https://wind-river-5693.herokuapp.com 2>&1 | grep certificate
* Server certificate: *.herokuapp.com
* Server certificate: DigiCert SHA2 High Assurance Server CA
* Server certificate: DigiCert High Assurance EV Root CA
-bash-4.1$ ACM handles all aspects of SSL/TLS certificates for _custom domains_;
you no longer have to purchase certificates, or worry about their
expiration or renewal.
And what pays for that engineering work? The money you make from having the feature.
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.
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.
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-berkel...
No. And people are under no obligation to not criticize them for not doing so. That's the thing with obligations: they are the bare minimum one must do, but hardly a guide for what one should do.
In fact, as a publicly traded company (as a subsidiary of Salesforce), they're actually obligated to maximize revenues and profits.
In my opinion, even if it was true, people should avoid mentioning it out of sheer embarrassment for the mockery it makes of a presumably advanced society. But it's not even true!
https://corpgov.law.harvard.edu/2012/06/26/the-shareholder-v...
You're correct, of course, and given the general libertarian mindset of HN, this is not a logically unreasonable stance to take. I don't even have a snarky "you'll be sorry in the future"-type parting shot to make because this is a niche of a niche we're talking about here.
I will just strike Heroku from the list of companies I will ever support and suggest my company and colleagues do the same. The same way I struck Startcom from that list after Heartbleed.
Hopefully, I change a few minds. Really all I can do.
Just in case it's not clear, these aren't rhetorical questions - genuinely interested in your answers.
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.
It's unreasonable because they provide what you are asking for at a free price point and you're complaining "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.
This is simply not true. Implementing LE support for more than a handful of domains is a significant amount of work, particularly when you don't control the domains in question.
Given that they already have the infrastructure in place and have just arbitrarily turned it off, these complaints of scale ring quite hollow. The storage and data transfer involved is tiny.