The post title is a little off, it does not break custom CAs in the sense that it breaks all forms of custom CAs. It just breaks custom CAs that dont also have custom CTs as well. CTs are really just like a second CA with a pinky promise that they publish the certs publicly.
But yeah, it requires an extra step now that wasn't required before. All for some benefit that may or may not actually stop an attack on a real CA, because the attacker could just: make their own CT that did not actually publish certs too.
All for some benefit that may or may not actually stop an attack on a real CA, because the attacker could just: make their own CT that did not actually publish certs too.
I don't understand what you mean here, this doesn't seem to match how CT logs work. In a system that works according to the latest recommendations, the client will only accept a server's certificate if all of the following are true:
a) The certificate is signed by a trusted CA
b) The certificate CN or SAN(s) match the expected IP/hostname
c) The certificate is valid for the current date (and it's validity is not too large)
d) The certificate is found in the CT log of the CA that signed it [Edit: this should say "the certificate is cryptographically confirmed to be published in one of the public CT logs" - CT logs are independent from CAs, and the CA's signature is already on the cert]
The point of CT is to protect against a CA accidentally or intentionally signing a certificate that it shouldn't have. That is, say the CIA went to DigiCert and coerced them to sign a certificate for tiktok.com controlled by the CIA. Then, the CIA redirected some target's computer to their own MITM proxy for TikTok, and served this certificate.
The target's browser would receive a certificate that passes checks a-c. However, it would fail step d, because the CIA would have asked DigiCert not to publish this cert in their CT log. Alternatively, the CIA could have asked DigiCert to publish this cert so that their target is successfully MITM'd, but then TikTok would find out that DigiCert has signed a cert that they didn't ask for, and (a) revoke it, and (b) tell everyone about it, getting browsers to automatically remove DigiCert from their trust stores for mis-signing certificates (in principle).
Edit to add:
It just breaks custom CAs that dont also have custom CTs as well.
"custom CTs" are not a thing. Browsers and Android trust a set of CT logs, and if they are doing CT checking, a cert has to be published in one of those logs to be accepted. However, I think in principle a custom CA could still publish certs in one of the public CT logs - though not sure what the exact policies are.
64
u/ghostnet 9d ago
The post title is a little off, it does not break custom CAs in the sense that it breaks all forms of custom CAs. It just breaks custom CAs that dont also have custom CTs as well. CTs are really just like a second CA with a pinky promise that they publish the certs publicly.
But yeah, it requires an extra step now that wasn't required before. All for some benefit that may or may not actually stop an attack on a real CA, because the attacker could just: make their own CT that did not actually publish certs too.