Google Chrome plots a quantum-safe future for HTTPS

https://fed.brid.gy/r/https://nerds.xyz/2026/02/chrome-quantum-safe-https-mtc/

Today I published an update on the #Canonical supported #upki project, which brings browser-grade Public Key Infrastructure to Linux through the efficient #CRLite data format, with the core revocation engine now functional and available to test!

Beyond current progress, this post explores broader integration, performance, and future capabilities like Certificate Transparency enforcement and Merkle Tree.

This is all part of the effort to increase the resilience of #Ubuntu machines by default, but I hope it has a wider benefit on the Linux ecosystem going forward!

https://discourse.ubuntu.com/t/77063

#CertificateTransparency #PKI #Cryptography

It seems that OpenAI is scraping [certificate transparency] logs

https://benjojo.co.uk/u/benjojo/h/Gxy2qrCkn1Y327Y6D3

#HackerNews #OpenAI #CertificateTransparency #Scraping #Technology #News #HackerNews

Eric Brandes dropped Part 2 of our CT logs series. The performance gap is staggering.

Tiled logs: 100M+ records/day
RFC 6962: Low millions (with throttling)

Google throttles hard. Cloudflare's Nimbus is decent. Let's Encrypt's tiled logs absolutely fly.

Post includes working Golang code for both log types. Real implementations, not theory.

https://www.certkit.io/blog/searching-ct-logs-part-2

#CertificateTransparency #PKI

Certificate Transparency logs hold billions of certificates but searching them is brutal. crt.sh is slow, truncates results, and crashes constantly.

We built a better CT search tool at CertKit (free to use). Part 1 of my series explains why CT exists (DigiNotar hack), how it works, and the insane scale (96M certs/week).

https://www.certkit.io/blog/searching-ct-logs

#CertificateTransparency #InfoSec

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

#CertificateTransparency (CT) creates public, append-only logs of every TLS certificate issued, helping detect rogue or mistaken certificates.

Learn how CT has 𝐭𝐫𝐚𝐧𝐬𝐟𝐨𝐫𝐦𝐞𝐝 𝐢𝐧𝐭𝐞𝐫𝐧𝐞𝐭 𝐏𝐊𝐈: https://bit.ly/4gkK72Y

📰 Read now!

#DevOps #CloudSecurity #Encryption #Cryptography #InfoQ

#Heise:
"
"Passwort" Folge 40: Probleme mit Widerrufen, Verbindungsabbrüchen und anderem

Eine pickepackevolle Folge, gefüllt unter anderem mit kundigem Exploitbau unter Linux, einem HTTP2-DoS und millionenfachen Zertifikatsrückrufen von Microsoft.
"
https://www.heise.de/news/Passwort-Folge-40-Probleme-mit-Widerrufen-Verbindungsabbruechen-und-anderem-10632694.html

mp3: https://audio.podigee-cdn.net/2098722-m-7a844de5c304b67bf99d2ee327d88425.mp3

10.9.2025

Aaaa.. MS..

#CA #CertificateTransparency #Chrome #LetsEncrypt #Microsoft #MS #PKI #TLSZertifikat #WebPKI #Zertifikat