This sounds like something that HPKP ( https://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning ) could have prevented and CAA records ( https://letsencrypt.org/docs/caa/ ) could not. But HPKP is deprecated.
The issuing was detected almost immediacy thanks to CT, and as we move to shorter certificate lifetimes the impact is continually reducing.
The CAA record in dns is a weak link though.
General solutions are tricker, and it’s good that Google limits its “special” case. When bbc.com or al jazzera or cnbc or whatever is hacked that’s a problem that is only solved by generic solutions.
Which means that the risk to you or I or the general public is low.
But FWIW: it also tends to argue that this is the aftermath of a coordinated, targeted attack against a single high value target (or at most a small set of targets they could hit within the window). The attacker knew they had a gun with only one bullet, and we're just hearing the muzzle report.
Edit: Someone more curious than I am might be able to answer this by seeing when the CRLSet was published. https://github.com/agl/crlset-tools
When a company has 3 billion customers, there's no practical cert lifetime that really reduces exposure. Five minutes would sniff enough traffic to do significant damage; one day would impact a big chunk of their users and five days would be nearly 100%
HPKP was deprecated because it was too dangerous to be deployed in production.
What I'd like to see is the ability to use and utilise multiple TLS certificates and host keys on the same session so that all the keys could be rotated/phased in-band with cross-signing providing the authority.
Seeing any mere change in the signers faster than (say) 30 days should allow the browser/client-stack to generate a warning that "google.com may be actively under attack please call this number on the old certificate, codeword banana-alpha-lima-lima-sigma". No need to cross-publish the keys, just cross-sign and don't forget what you've seen previously.
The browser would be able to take policy of simply never trust a certificate whose signer has changed (since phasing is possible), and it wouldn't then need to consult more public oracles (DNS, certificate transparency, etc, that leak privacy).
I'd also like to get that webauthn hooked back into TLS client certificates: If we had 1997 again instead of passkeys that also would've stopped this.
This assumes that the signer's keys can't be compromised, and re-introduces the issues of key pinning that the WebPKI community has been pushing very hard to eliminate from its dependents. I don't think it's a workable solution.
Or, if the signer's keys are compromised, how do you switch to a non-compromised signer without alarms triggering?
The problem is almost exactly the same as one with a delegated CA -- if the CA keys are compromised, you have to re-issue all certs. When the client pins the CA key then the chain of trust is permanently broken.
You mean, hypothetically if Letsencrypt suddenly loses the ability to sign new requests from me?
Well, then I have around 30 days to detect that and choose a new signer.
> Or, if the signer's keys are compromised, how do you switch to a non-compromised signer without alarms triggering?
Again, to be clear, you're talking about Letsencrypt's own signing keys in this case, being compromised and them being denied access to them. That seems incredibly unlikely to have both failures at the same time, but again: I have 30 days to find a new signer.
> The problem is almost exactly the same as one with a delegated CA -- if the CA keys are compromised
No! In fact, if Letsencrypt sublicenses signing to a third-party that certificate would be considered separate and so the switcheroo would be detected!
> When the client pins the CA key then the chain of trust is permanently broken
That's why it is important to extend TLS to allow multiple keypairs and certificates to be used to mutually authenticate the session key, so that any of the previous pinned keys can be used to update the pin. I did not say I wanted this for no reason!
Therefore either
1) Letsencrypt ignore CAA records (unlikely)
2) The DNS hijackers removed the CAA record 12+ hours before doing their attack and google did not notice (I'd hope unlikely)
3) Letsencrypt querys did not return a cached CAA record because their resolvers had not been asked for it, so removing the CAA record a few minutes before hand worked.
> .com may be actively under attack please call this number on the old certificate, codeword banana-alpha-lima-lima-sigma
Do you seriously think this is an appropriate message to give to Aunt Irene?
If your CA certs are bad on your mobile application, you can push an out-of-band update via the device's app store.
If your CA certs are bad on a website you access via your browser, the means of updating them is... the browser. You can't get new certs without using a TLS connection you didn't want to trust anyway.