💾 Archived View for gem.snowgoons.ro › posts › 2020-06-11-ssl-is-broken › index.gmi captured on 2023-09-28 at 15:58:12. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-10-31)
-=-=-=-=-=-=-
I hate TLS/SSL.
There, I said it. I've long thought it, for various reasons, but it's hard to admit... In a world where everyone now uses TLS for everything (for laudable, if in my view wrong-headed reasons) it's hard to be the one that says "why are we wasting thousands of CPU cycles encrypting completely open, public information that has no need to be encrypted, when a more lightweight mechanism that just handled the authentication side of things (i.e. knowing the data was coming from who you expected it to) would be more than adequate, and could be implemented without basically breaking caching everywhere." And let's be honest, now that SSL is everywhere, the most important function it serves the regular consumer - that "is this site the site I think it is" question - is completely lost, because no consumer has the faintest idea what the padlock in their web browser means any more.
But that's not actually what today's rant is about; the SSL everywhere battle was lost a long time ago (thanks, Google.)
Today's rant is that SSL/TLS is just goddamned broken in implementation, and design.
My most recent personal fight with SSL was an entirely predictable one - cross-compiling a small Rust project I'm developing on for ARM was going swimmingly right up until the web-service element needed to be built. Then we suddenly enter a world of code libraries that are a mish-mash of C and assembler, that have dependencies on floating point libraries or support that either don't exist or require incantations with a dead chicken to build, and when they do fail in mightily curious ways because, well, just because that's what always happens as soon as you look at an SSL library.
The fact is, SSL/TLS libraries and certificate management is just a pain in the arse. This leads people to end up taking shortcuts, like disabling TLS in their Kubernetes environment because the supposedly automated certificate management isn't working for mysterious reasons, or just hacking in self-signed certificates into a project that they'll definitely get round to doing something about 'properly' some day (usually, 'some day' being years in the future when the self signed certificate expired and a major production incident was created). The net effect is that the illusion of security is enhanced, but the reality is security holes are opened up all over the Internet, because getting things working right is so much harder than just hacking things into submission.
The other problem is *the whole damned infrastructure is just buggy*. The most recent cockup was this:
TLS clients not capable of building an alternative certificate chain stopped working correctly when connecting to servers which advertise a certificate chained to the Sectigo root CN = AddTrust External CA Root on May 30, 2020. These servers direct clients to the expired root by supplying one of several possible intermediate certificates that expired at the same time.
To address the problem across platforms, administrators of affected TLS servers must configure them to not advertise the expired Sectigo root CA certificates (see the Quick Fix Details section).
In short, anyone with certificates with Sectigo certificates in the chain had a bad weekend as thousands of clients stopped working because of a bug in how they validate certificates. And this is hardly an unusual case, it's just the most recent...
But there is one more, much more fundamental problem:
You can rely on the certificates that secure your connections because you trust the people that issued them, right?
The whole system is broken. Surely we need to come up with something better?
--------------------