HTTPS is insecure
2021-01-24
The general presumption of HTTPS is that it is encrypted, safe, and trustworthy. Primarily, the thinking is that it prevents man-in-the-middle attacks.
None of this is actually true in practice.
Logjam
In 2015, Logjam was announced. There’s some technical details there (which I won’t regurgitate since they’re right there), but the gist is that a Diffie-Hellman key exchange is broken for 512bits, and up to 1024bits is attackable by large entities such as nations or tech companies. This was in 2015, by this point it is reasonable to expect that even larger are vulnerable. Ultimately, this means Diffie-Hellman is broken.
While there is some pushback, which doesn’t refute that the attack works, but only that the attack would be able to attack a lower percentage of traffic than estimated. That’s… not very comforting, since this admits that if someone were to sniff your traffic, retain it for a few years until they had spent the necessary money to crack your key exchange; you’d be out of luck.
While the idea that anyone is keeping full encrypted TLS sessions laying around, it’s not impossible. This is exactly how one attacks this kind of traffic; anyone who has sat in a cafe running aircap is doing the exact same thing. With the explosion of both storage, processing, and techniques (even since 2015) it would be irresponsible to assume that this proven attack on DH is not a problem for the future.
Elliptical-Curve
Before moving on, I’d be remiss if i didn’t mention that if your cert/server specifies the newer EC process, instead of PKCS, you’re fine. But this is a pretty rough thing to try to enforce; most servers use the Mozilla-Intermediate scheme, which allows negotiation of plenty of Logjam-able ciphers. It’s been 6 years but the landscape is still surprisingly grim.
But if you can, you should still generate an ECDSA cert.
Trust
Certificate Authorities (CA) are a huge weakness in the HTTPS cycle. Any root CA can vouch for any domain, regardless of if that domain is even aware of the CA. This leads to several notable attacks, such as DigiNotar. Root CA are, in effect, able to lie about who you’re talking to. The whole point of talking to a CA is to verify that someone is who they say they are; a hard problem.
In short, the problem of trust is that you cannot identify someone based solely on things they tell you; you must have some outside reference to vouch for them, or at least offer a challenge that only their claimed identity could satisfy.
The entire "chain of trust" model of X.509 / CA is broken in its design; since it means that now anyone who compromises the root CA (by hacking, legal pressure, etc) can now masquerade as anyone. Instead of solving the problem of trust, it simply made people forget about it.
Web of Trust
This was originally going to be solved by the web of trust, whereby you’d manually keep a list of identities you trusted, and would communicate with trusted identities to determine if a stranger communicating with you is legit. This is a good model, and still is the only model for solving the problem of trust at scale - but it hasn’t taken off since it’s difficult to get random people to remember a single password, let alone keep a private key truly private.
DANE
DANE, while not removing all the problems with root CA’s, at least creates a way to have sites specify which root CA is allowed to vouch. That’s better, even if imperfect.
Naturally, DANE relies heavily on DNS, which is a protocol which is typically unencrypted. Even if you’re one of the .01% of humans using DNS-over-TLS (or https), you must suddenly be faced with the problem that root CAs affect your DNS query that would get the DANE record. Naturally, this is as much a half-solution as CA’s are.
Nothing to fear?
Generally, the response to all this has been pretty quiet. After all, we’re talking about a pretty heady attack vector, involving hundreds of millions of dollars spent attacking Diffie-Hellman, or compromising a root CA. Sure, we have examples of both things happening, and we know nothing has been done to reduce that risk - but isn’t it a bit far fetched? Isn’t this more of a state-actor kind of thing?
The answer is "yes, but…" - these can equally easily be deployed against regular people. State actors have strong incentives to deploy these kind of attacks on dissidents, or rival political organizations. Just because you’re not one, doesn’t mean you want everyone to cede their security.
In the short term, use ECDSA, make a DANE record, and spread the word.
