Yesterday, Mozilla made a blogpost, stating that they will be "deprecating non-secure HTTP" - in other words, forcing HTTPS. I believe that this decision is harmful to the open web, and this is why.

First of all, for those who are not familiar with me - I actively encourage people to use SSL/TLS wherever possible. I do not believe that there is data that is "not important enough to encrypt".

I do however believe that there are fundamental problems with the way TLS is currently deployed in practice, problems that absolutely need solving before a forced global deployment of TLS can happen.

TLS is broken

Yes, it's broken. Any certificate authority in the world can sign a certificate for any hostname in the world, regardless of whether that's the actual CA being used by the real owner of that hostname. This means that anybody with access to the signing infrastructure of any certificate authority anywhere in the world, can sign fake certificates for everybody else.

While TLS can still provide data confidentiality against passive attackers, and this problem can be circumvented in custom applications and API libraries by hardcoding a certificate or CA into the client, it is very much broken in the common "TLS on the web" implementation.

Certificate pinning is suggested as a 'solution', but still requires to trust the certificate on the first connection, and it doesn't provide an easy migration path for service operators who want to switch their certificates to a different certificate authority. It's also still not actually implemented by major browsers.

SSL certificates are a racket

It's really that simple. You are essentially forced to pay for a certificate if you want to use TLS. If you do not, and try to use a self-signed certificate, a browser will show a scary warning page to your users. You can't even embed (iframe) pages using self-signed certificates at all. The browser will simply refuse to load the page, not even showing a warning.

Domain-validated certificates have a cost of practically zero to generate. It's all automated. Higher-validation certificates have a non-zero, but still trivial cost to generate - the cost is purely in the validation work, which is generally a repetitive and largely automatable job.

Higher-validation certificates generally do come with insurance, but there is no way to 'opt out' of this if you don't need it - as is the case for the majority of non-corporate uses of an SSL certificate.

In short; the true cost of an SSL certificate is generally several magnitudes lower than what you're being charged for it. And everyone charges like that. It's a racket.

Startcom is not actually free

"But Startcom gives away free certificates!", you say. Well, no, not really.

The domain-validated certificates that Startcom provides are indeed free to generate. Revocation, however, even in the situation of a global security issue that is completely out of your control, will cost you money.

Revocation is a vital part of a secure TLS cryptosystem. If you don't pay Startcom, you are unable to revoke, and this breaks the security model of TLS. Your security is broken.

Startcom is not really free.

Let's Encrypt is not a complete solution either

"But," you say, "Let's Encrypt is just around the corner!"

It is. It will also - at least, initially - only offer basic domain-validated, multi-host certificates. It is apparently undecided as of yet whether wildcard domains will be supported. Other scenarios may also not be supported.

"But if you need a wildcard certificate, surely you have the money to pay for it?" Well, no, not necessarily. Right now, I'm building a free CDN for non-commercial projects. This would ideally let me provide a separate subdomain for every user - something that isn't feasible without a wildcard certificate, if TLS were to be enforced. I don't have the money for such a certificate - keep in mind that this is all non-commercial - and it would be ludicrous to expect otherwise.

"But you can just generate a new certificate for every subdomain!" Yes, you could. In complex setups, however, that quickly becomes a bookkeeping nightmare. You now have to add infrastructure for the specific purpose of propagating TLS certificates across multiple frontend servers. Not to mention that if Let's Encrypt goes down at any point, your entire registration system is down.

And on top of that, Let's Encrypt is only one certificate authority. If they are ever removed from browser trust stores - don't forget that it is still very experimental - you have exactly zero alternatives, other than to suddenly pay for some other CA.

"But you can still use HTTP!"

Yes, but you will not be able to use many new features. A quote from the original article:

For the first of these steps, the community will need to agree on a date, and a definition for what features are considered “new”. For example, one definition of “new” could be “features that cannot be polyfilled”. That would allow things like CSS and other rendering features to still be used by insecure websites, since the page can draw effects on its own (e.g., using <canvas>). But it would still restrict qualitatively new features, such as access to new hardware capabilities.

Those features are not disabled for 'security reasons', as some people in the comments on the Mozilla post have suggested. They are disabled to pressure you into using TLS.

"But you won't need those features!" Maybe you do, maybe you don't. Isn't the point of an 'open web' that the same features are available to everybody, regardless of financial means or other qualifications? Hell, I personally use many newer features to build non-commercial projects.

Conclusion

In conclusion; no, TLS certificates are not really free. Introducing forced TLS would create an imbalance between those who have the money and means to purchase a certificate (or potentially many certificates), and those who don't - all the while promoting a cryptosystem as being 'secure' when there are known problems with it. This is directly counter to an open web.

There are plenty of problems with TLS that need to be fixed before pressuring people to use it. Let's start with that first.