Companies who aren't in the business of selling TLS [0] certs themselves have little excuse to not offer free TLS via Let's Encrypt. It's an advantage over any competitors who haven't set that process up.
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.
A bunch of folks have started calling the ones used for websites 'https certs' since 'https' actually appears in the browser UI and 'tls/ssl' is unwieldy.
If you have a free plan at all, then the only reason TLS should not be a paid feature would be if you intentionally want to position the free plan as "don't take this seriously because you can't build anything production-quality on it".
> If you have a free plan at all, then the only reason TLS should not be a paid feature would be if you intentionally want to position the free plan as "don't take this seriously because you can't build anything production-quality on it".
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.
There are ways of doing that without sacrificing security. Making TLS a paid-only feature makes no more sense than making CSRF protection a paid-only feature.
Considering the amount of crap ISPs have been known to inject into websites, I disagree. TLS isn't just for encryption, it also provides data integrity.
Yes it does. Stop spreading this misinformation because it is dangerous. Everything should be encrypted. I don't want people knowing that I'm reading your blog or what on it I am reading.
Now who's spreading misinformation? HTTPS doesn't protect the fact you're reading a blog (the IP of the server will be observed, and typically the server name through the cert itself) and while one can't prove which URLs of the server you visited one can infer based on the amount of traffic sent.
There's a pretty significant difference between someone being able to tell, for example, that you visited medium.com, and that same someone being able to tell exactly which blog post you read because the whole request is unencrypted.
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.)
Because your competitors will do so and the paid plan should be to paying for bandwidth or storage space, not TLS. Now you just lost your lunch to competitors who aren't trying to nickle and dime their customers.
>Hosting a static free blog doesn't need TLS.
Completely wrong, although others explained why already.
For anyone on the fence about using Heroku, this is a great value to those who know how to deal with certs but wouldn't mind them automated and free for the rest of the premium at Heroku.
Awesome. With the Hobby Dyno pricing and no effort support for Let's Encrypt, Heroku is really hitting a sweet spot for supporting low volume web apps (e.g., less that a 1000 daily visitors).
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.
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.
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.
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.
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.
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.
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):
But this is all engineering work that needs to be done for the system at all. None of these things have incremental costs that justify hiding encryption behind a paywall.
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+.
They aren't generating certs on the fly for randomly named dynos:
-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.
Saying that "that's only 20 gigabytes worth of certs" is roughly equivalent to saying "this database is only 1.8TB - that's miniscule, 2TB drives are only $70!". There's a whole lot more moving parts, especially at scale (developing a system to manage 5M certs? Pretty sure that's a whiteboard interview question somewhere).
Please read this conversation with the context in mind rather than replying to the one statement. When you're referring to costs as a category, as that statement was, the "moving parts" aren't factored into storage costs.
I have, and I believe that you're being extraordinarily reductionist about the true costs involved in developing and operating services like certificate management at scale.
> 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.
They are offering SSL free to all free dynos under the 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.
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.
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.
Heroku is not a non-profit/government organization. They are not under the obligation to advance the public good.
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!
And we end on the "maximize shareholder value" argument, the be-all end-all cop-out non-argument when a company is behaving harmfully.
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.
I don't want to just jump all over you like some people are doing, because I think you make somewhat of a valid point (to be honest, I don't think I'm knowledgeable enough to have an opinion there). However, it's my understanding that you can SSL any app by default using their wildcard for free. As a private business, is it really so wrong for them to restrict the free, automated LE certs to just paid apps? If so, why?
Just in case it's not clear, these aren't rhetorical questions - genuinely interested in your answers.
you dont pay for SSL in this case. SSL is free. You pay for SSL on your domain. You can have SSL for free, if you let heroku advertise through your URL. Seems like a fair deal.
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.
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.
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!".
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.
> The level of labor for Heroku enabling for everyone is negligible
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.
Not when you control the endpoint that the domain will be pointed at, as Heroku does. LE verification via file consists of files shoved in the web root at /.well-known.
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.
I hope the other PaaS will follow.