There are plenty of ways you would never be able to tell if a fake cert had been generated and used via this attack vector (let's ignore validation attacks):
1. CT does not do anything if a state actor demands a CA in its borders generate a cert without publishing to the CT logs (or a three-letter-agency doing this illicitly). They can put SCTs in the cert, and still not publish to the logs, nobody is auditing the logs for every cert every browser sees.
2. Browsers won't check for SCTs in certs if they come from a private CA. you can MITM any domain through ZScaler all day long and nobody will notice
3. Wildcard certs make it easy to make/renew a cert that looks normal but hides requests on new/different hosts
“They can put SCTs in the cert, and still not publish to the logs, nobody is auditing the logs for every cert every browser sees”
I don’t think you can get the SCT from a log without the log publishing it? That would defeat the purpose.
“Certificates that support certificate transparency must include one or more signed certificate timestamps (SCTs), which is a promise from a log operator to include the certificate in their log within a maximum merge delay (MMD).[4][3] At some point within the maximum merge delay, the log operator adds the certificate to their log.”
I feel somewhat confident in speculating that a bunch of people at large companies will, in fact, be auditing the logs following this. That’s their main value; they’re not really an online/active prophylactic.
I admittedly don't know much about how CAs work but why would a state actor care about such an exploit? Wouldn't they just ask any local cert issuer and receive a "legitimate" cert?
If FBI went to Godaddy and said, “We need a cert for www.google.com”, Godaddy would most likely refuse. Issuing that cert would leave a trail that would be extremely undesirable for both FBI and Godaddy.
They are not exclusive to each other. The most successful criminal organizations work with, and from within, nation states, their intelligence agencies and law enforcement. Oh hi, we see you.
Nope. You can find this from the Chrome Root Program.
> Because no TLS certificates chaining to these six intermediate CAs were logged to CT prior to our CRLSet block on October 17, no fraudulent certificates issued by these CAs could have been trusted by default in Chrome or other CT-enforcing browsers.
The Web PKI uses certificate transparency, so we’ll have a definitive answer about whether this is/was exploited soon.
(But in any case, CT ensures that it can’t be “quiet.”)
There were no certificates from the compromised intermediates logged to CT prior to remediation by the browsers.
Which is good because certificates not in CT logs are treated as invalid/untrusted.
2 replies →
CT is great for browsers. Largely irrelevant for anything being fetched outside of a browser.
That’s why I’m talking about it purely in the context of incident response/forensics.
29 replies →
CT is enforced in Android 17 by default.
There are plenty of ways you would never be able to tell if a fake cert had been generated and used via this attack vector (let's ignore validation attacks):
1. CT does not do anything if a state actor demands a CA in its borders generate a cert without publishing to the CT logs (or a three-letter-agency doing this illicitly). They can put SCTs in the cert, and still not publish to the logs, nobody is auditing the logs for every cert every browser sees.
2. Browsers won't check for SCTs in certs if they come from a private CA. you can MITM any domain through ZScaler all day long and nobody will notice
3. Wildcard certs make it easy to make/renew a cert that looks normal but hides requests on new/different hosts
4. Non-Browsers do not validate SCTs
“They can put SCTs in the cert, and still not publish to the logs, nobody is auditing the logs for every cert every browser sees”
I don’t think you can get the SCT from a log without the log publishing it? That would defeat the purpose.
“Certificates that support certificate transparency must include one or more signed certificate timestamps (SCTs), which is a promise from a log operator to include the certificate in their log within a maximum merge delay (MMD).[4][3] At some point within the maximum merge delay, the log operator adds the certificate to their log.”
2 replies →
I feel somewhat confident in speculating that a bunch of people at large companies will, in fact, be auditing the logs following this. That’s their main value; they’re not really an online/active prophylactic.
I admittedly don't know much about how CAs work but why would a state actor care about such an exploit? Wouldn't they just ask any local cert issuer and receive a "legitimate" cert?
If FBI went to Godaddy and said, “We need a cert for www.google.com”, Godaddy would most likely refuse. Issuing that cert would leave a trail that would be extremely undesirable for both FBI and Godaddy.
You could cloak where it's coming from more easily this way.
organized crime is generally as or more capable these days. they have bigger budgets than most nation states.
They are not exclusive to each other. The most successful criminal organizations work with, and from within, nation states, their intelligence agencies and law enforcement. Oh hi, we see you.
A grumpy state actor today.
Nope. You can find this from the Chrome Root Program.
> Because no TLS certificates chaining to these six intermediate CAs were logged to CT prior to our CRLSet block on October 17, no fraudulent certificates issued by these CAs could have been trusted by default in Chrome or other CT-enforcing browsers.
Not all TLS traffic involves a browser.