alt Hacker NewsYes this is to be expected. I've mentioned multiple times over the years that TLS CA issuance & validation's many security holes (>=14 at last count) could be solved by changing how certificates are issued. I've never had the kind of clout to get that message wide enough that anyone would take it serious.
One of Web PKI's security holes is the fact that any CA can issue valid certs for any domain. The only official "mitigation" for that is voluntary and can be defeated.
The solution to that is to rearchitect the Web PKI ecosystem to use domain registrars as the sole source of truth for which CA is allowed to issue valid certs, in addition to cryptographic fingerprints of the source of the originator and issuer. I won't rehash it here but it's not technically difficult and would make it so only the domain owner could issue certs, and valid certs could only come from the CA the domain owner authorizes.
Maybe if this keeps happening, people will realize it's worth working on? But I doubt it, as a lot of money is at stake, and nobody wants to risk that just to stop governments and cybercriminals from spying on the occasional connection. If it was blatant and obvious then they might have to act; as long as it's kept covert and hard to prove, things stay the same.
Replies
If the wrong CA issued a certificate then wouldn’t that show up in the transparency logs? It seems like by monitoring them, you could see if a security bug is being exploited.
How would clients receive the trusted CA data from the registrar? DNS?
This would very easily be susceptible to MITM attacks. Any DNS security to prevent MITM attacks is going to have the same CA issue we currently have.
> One of Web PKI's security holes is the fact that any CA can issue valid certs for any domain. The only official "mitigation" for that is voluntary and can be defeated.
In case you were not aware, Moxie Marlinspike spoke about this at length back in the early 2010s[1]. His view was that the problem is that certificate authority trust is controlled by the wrong people (web hosts, not users -- or browsers, as a proxy for user wishes) and is not possible to revoke because once a web host uses a particular CA you are stuck trusting them forever otherwise the internet will break.
> The solution to that is to rearchitect the Web PKI ecosystem to use domain registrars as the sole source of truth for which CA is allowed to issue valid certs, in addition to cryptographic fingerprints of the source of the originator and issuer. I won't rehash it here but it's not technically difficult and would make it so only the domain owner could issue certs, and valid certs could only come from the CA the domain owner authorizes.
Unfortunately, this is problematic for a bunch of other reasons. Yes, this means that a classic Comodo or DigiNotar attack might be blocked (though it is also just as likely they would've been included on the allow-list for American websites), but it also means that registrars could force you to use VeriSign and you would have no choice in the matter -- that is what originally happened with TLS and was what originally happened with DNSSEC too. It seems prudent to me to avoid creating schemes that allow that kind of institutional capture.
There is also in my view a mistake to assume that anyone with a ".com" or ".us" address would want to have the US government decide who they can get certificates from, ditto for any national TLD (let's not forget all of the Rust projects with ".rs" which is controlled by Serbia, tech websites with ".io" that is controlled by the UK, and so on).
If you really wanted to do this, DANE would allow website owners to do this by pinning the CA root and intermediate certificates hashes via DNSSEC -- basically acting as a client-side (and more strict) version of CAA (which I'm guessing is what you were referring to in your comment). Unfortunately it's not supported by Chrome and Firefox, and it would be quite fragile. It would be nice to have this as an option, and I am quite disappointed with the fact that clients are expressly forbidden from parsing CAA by RFC 8659.
[1]: https://youtu.be/UawS3_iuHoA?t=292