Comment by Gigachad
5 hours ago
This is stopped by certificate transparency logs. Your software should refuse to accept a certificate which hasn’t been logged in the transparency logs, and if a rogue CA issues a fraudulent certificate, it will be detected.
I don't believe it's supposed to proactively check the logs as that would inevitably break in the presence of properly configured MITM middleboxes which are present on many (most?) corporate networks.
The point of the logs as I understand it is to surface events involving official CAs after the fact.
Clients are supposed to check. For example, Apple requires a varying number of SCTs in order for Safari to trust server certificates. https://support.apple.com/en-us/103214
And yes, it does break MITM use cases, for example on Chrome: https://httptoolkit.com/blog/chrome-android-certificate-tran...
So how does that work with middleboxes? Corporate isn't about to forgo egress security (nor should they).
I don't currently MITM my LAN but my general attitude is that if something won't accept my own root certificate from the store then it's broken, disrespecting my rights, and I want nothing to do with it. Trust decisions are up to me, not some third party.
Certificate transparency doesn't prevent misissuance, it only makes detection easier after the fact. Someone still needs to be monitoring CT and revoke the cert. I actually believe most HTTP stacks on Android don't even check cert revocations by default.