ICYMI:

**Globalsign certs issued on Monday 1st Dec 2025 will not be trusted on some clients because they incorrectly use 2027 CT logs.**

You can simply reissue them to resolve the problem.

https://status.globalsign.com/incidents/49ndl5hz24h2

#PKI #GlobalSign #WebDev #TLS #CTLogs

First I must underline that this is all speculation and I have no proof of the attack described here being implemented in practice.

I firmly believe too much trust is placed on the effectiveness of certificate transparency to protect against state actors.

Much focus has been placed on the fact that certificate transparency is supposedly geographically and jurisdictionally distributed and could not be defeated by a single state. Unfortunately, the monoculture of Chromium-based browsers means that a single point of failure now exists, easily tampered with by a single jurisdiction: the USA.

From checking I've done so far, it seems that most Chromium-based browsers use the Google-generated "PKI Metadata" package as is. This would include browsers such as:
- Google Chrome
- Microsoft Edge
- Vivaldi Browser
- Brave Browser

Assuming the actor would have ability to sign malicious "PKI Metadata" update, this would mean that the actor would also have the ability to disable certificate transparency by targeting the periodic "PKI Metadata" update performed by the Chromium component updater.

In practice the attack would replace the "ct_config.pb" file with one that lists fake servers that are all in control of the attacker and that would provide a fake Merkle tree against which a crafted certificate would then validate. No collusion by the CT log providers are required as the actual list is replaced by malicious one. Once done, the actor who has the ability to issue otherwise trusted certificates can bypass certificate transparency and quietly get MiTM performed. In effect, CT validation would still happen, but it would be performed against infrastructure fully controlled by the attacker. Notably to implement this attack no changes to Chromium source code or binaries would be required, only the component updater signing key would need to be made available to the actor.

I am not claiming that Google would necessarily be doing something like this, or that they would be doing this willingly. The United States law, however, has binding clauses that require US companies to cooperate to provide lawful access. Notably, this law also specifically only protects US citizens, and everyone else can be targeted freely. This is why Certificate Transparency was planned to be distributed between multiple jurisdictions to begin with.

Apple and Mozilla manage their certificate transparency log lists separately. Thus, they're outside of this single point of failure, at least. This doesn't necessarily mean they would be unaffected by similar lawful access requirements, however.

Having laid out the problem, is there anything that could be done to improve the situation? What should parties using Chromium do to rectify this situation and limit the potential impact from such malicious "PKI Metadata" updates?

I suggest that browser manufacturers that take security seriously stop blindly trusting Google to deliver "PKI Metadata" updates. Rather, they should set up infrastructure of their own that delivers this (and potentially other?) component updates. The service would then add an extra layer of validation, where the Google-provided update is verified (by automation and potentially manual means) before being repackaged and signed with their own trust root.

Of course, this method isn't bulletproof either, as these individual signing parties could then be targeted by the state actor. However, it would be a far better situation than trusting a single company in a single jurisdiction for this certificate transparency list.

In the end you need to trust something at some point. I would like to place my trust on something else than good will of US government.

#privacy #certificatetransparency #chromium #bravebrowser #vivaldi #ctlogs

Anyone else just getting 502s when using crt.sh, searching for CT logs on domain names?

The index page works, although I'd argue with degraded performance. Any search on the site however does not.

Can someone confirm? Or is it just me?

#downdetector #crt.sh #certificatetransparency #ctlogs