Hacker News Reader

Comment by btown | Hacker News Reader

What are the state-actor-level attack implications of this? Before this was revealed, a party that compromised (or was able to be issued) a certificate for a website could be reasonably likely to be detected and have that certificate revoked if they used it for large-scale MITM or redirection. But now, if the actor were to also compromise any one of these sub-CAs before the key was deleted, could they permanently be in a position to be able to unilaterally reverse any such revocations, effectively giving them carte blanche to begin a campaign of compromising websites in earnest with the knowledge that their attacks would now be "sticky?"

What would the recourse be here if one of those keys were to be compromised, or even if there was reason to believe one might have been? Would the entire CA-level trust chain need to be distrusted, requiring re-issuance of all certificates on that chain?

View on HN

Yes and almost-yes - you don't need to destroy the root CA itself, but you need to physically destroy the keys for any affected subordinate CAs. (Revoking them isn't sufficient, because they can just un-revoke themselves.) From the post: "... the degree of this issue likely also justifies requiring witnessed Key Destruction Reports, in order to preserve the integrity of the issuer of these certificates (which may include the CA's root)."

The "good" news is that most people haven't really been treating revocation (and OCSP) as a reliable mechanism. The major browsers all have out-of-band mechanisms for revoking known-malicious certs via something equivalent to the software update channel, which bypasses reliance on the CA infrastructure. If there's a large-scale attack, the relevant cert/CA will probably be disabled through that mechanism. And most of the smaller clients don't even bother with revocation checking at all (e.g., I'm pretty sure that on an average Linux system, things like curl or "import requests" do no revocation checking) so there's no point in undoing revocation if you're trying to attack one of those systems.

> e.g., I'm pretty sure that on an average Linux system, things like curl or "import requests" do no revocation checking

This is correct. Even where there's some provision for checking, it's usually a mechanism where you can supply a CRL (Certificate Revocation List, a signed and dated document that says which certificates were revoked). CRLs are practical for a small private CA but they make no sense at scale. Let's Encrypt doesn't even have CRLs because they'd be enormous.

To be fair 10-15 years ago there's a good chance that average Linux system has a set of CA roots which hasn't been updated in a decade, and most such clients aren't actually checking even CN let alone SANs so bad guys don't need a google.com certificate (or whatever) they can just get themselves a real certificate for actual-bad-guys.example and the client won't check the name matches anyway.

Having sadly worked with plenty of developers whose first reaction to an invalid certificate error is to Google how to disable the checking, I don't think you need to go back 10-15 years.

Interesting. I do imagine there are a nonzero number of systems that do revocation checking without out-of-band mechanisms, and that those would become susceptible. But all such systems are likely vulnerable to unpatched zero-days anyways, so this may not make things any worse than they already are :/

> What are the state-actor-level attack implications of this? Before this was revealed, a party that compromised (or was able to be issued) a certificate for a website could be reasonably likely to be detected and have that certificate revoked

This is a convenient fiction. CA system never protected anyone against state actors. Never did, never will. Subverting a single CA is enough to compromise entire system. And there are hundreds of them.

Security is always grounded in knowledge and physical control — understanding and exercising your capabilities to preserve them. A blind, deaf and fully paralysed person can't be expected to safeguard their own physical security, and neither can an average user — their TLS security. Especially against state actors. More so, when the parties they have to rely on are commercial enterprises whose entire existence revolves around getting paid to issue certificates.

Reply on news.ycombinator.com