lobsters score: 4 · tags: security
It’s wild that the best possible model for encryption globally is apparently, “75 random companies from dozens of countries are trusted to never ever mess up, and if any of them mess up even once or buckle under pressure from their government all encryption on the web breaks”
score 1 · canonical
My poorly-informed prediction is that the root CA store will become less relevant, since browsers will adopt Merkle Tree Certificates and will only trust these new CT-style CAs, which will be run as public-good type services.
These random 75 companies will continue to have signing keys trusted by a dwindling set of tools that don’t adopt Merkle Tree Certificates.
It’s of course not that simple. Customers pay for CAs in part for typical enterprise support reasons, and will expect to have Merkle Tree Certificates too. DNS-PERSIST-01 will facilitate that, since it offers trivial means for a domain-owner to delegate requesting issuance to a 3rd party. i.e. enterprise.com will continue to pay eMudhra.com, and by delegating DNS-PERSIST-01 to eMudhra.com, then eMudhra.com will be able to request that the CT-style CAs issue certs for enterprise.com. It just won’t be signed by eMudhra.com’s key.
The benefit is that this is inherently name-scoped: eMudra.com is only able to get certs for customers that have delegated to it.
score 1 · canonical
How do merkle trees fix it? The core problem is that someone has to be a trusted party which sits on a private key, and due to politics, every country wants to be such a party
score 1 · canonical
The current PKI system gives too must trust to too many parties. Further, the trust it gives to each CA is more trust than should be given to anyone.
The PLANTS working group are working on a new PKI, well explained here:
“[Merkle Tree Certificates] replace the heavy, serialized chain of signatures found in traditional PKI with compact Merkle Tree proofs. In this model, a Certification Authority (CA) signs a single “Tree Head” representing potentially millions of certificates, and the “certificate” sent to the browser is merely a lightweight proof of inclusion in that tree.”
https://blog.google/security/cultivating-a-robust-and-efficient-quantum-safe-https/
In this model, a CA is a CT log, and so the trust given is very minimal since it’s auditable by third parties.
due to politics, every country wants to be such a party
In MTCs, there is no party given the amount of trust that a current CA gets. (By design!)
But countries/organisations do still want more support/coordination than “everyone just run an ACME client”, and this is what DNS-PERSIST-01 enables:
.gov.ukcan delegate issuance privilege to a UK-based PKI organisation, who can run ACME for any domain undergov.uk, after doing whatever internal service auth that UK gov wants to do. This UK-based PKI org can monitor expiratoin/rotations, have custom internal UIs/dashboards, offer support, etc.This level of support/integration has only been viable with root/intermediate CAs so far, which is a factor in why there are so many, leading to this tension of “more CAs is good for choice, but bad for trust”.
So to answer your Q, I’d say it’s really DNS-PERSIST-01 that provides the opportunity for PKI root stores to be shrunk, and it’s PQC/PLANTS that will further reduce that trust, but also be the impetus.
https://blog.google/security/cultivating-a-robust-and-efficient-quantum-safe-https/ also mentions:
Chrome has no immediate plan to add traditional X.509 certificates containing post-quantum cryptography to the Chrome Root Store
[…]
[Q3 2027]: This phase will also introduce the ability for sites to opt in to downgrade protections, ensuring that sites that only wish to use quantum-resistant certificates can do so.
Having read more about it, yes, it looks like root CA store will become less relevant, very soon!
score 1 · canonical
We have better models. For instance, we have DNSSEC with TLSA, which solves that problem pretty elegantly IMO. (It has some new problems, of course.) Sadly no browser even tries to validate TLSA records so nobody has any reason to configure them even if their domain uses DNSSEC.
score 1 · canonical
You should look up who runs the
.comand.netregistries, and who therefore controls the DNSSEC signing keys for those zones. DNSSEC signing keys which can be silently misused and undetectably selectively served to targeted clients, because DNSSEC has no equivalent of Certificate Transparency.How is this better?
score 1 · canonical
It’s better because I can choose a different TLD whose operators I trust. With the PKI, it doesn’t matter which CA I pick because all other CAs are still able to emit valid certificates for my domain.
DNSSEC has no equivalent of Certificate Transparency.
One can totally combine DNSSEC with CT. I didn’t suggest that DNSSEC/TLSA should fully replace all the existing checks browsers perform.
score 1 · canonical
It’s extremely wild that there are so many safeguards and policies in place about what you can and cannot do with the certificates but apparently nobody checks if the cryptographic key is…4?
score 2 · canonical
A lot of the safeguards also come from audits, but audits always have the issue where your customer is the one paying you to audit them.
As an auditor you want to let as much shit fly as possible as long as it doesn’t endanger your reputation, because no company will pay for the auditor that gives them more work when someone else will give them a pass.
score 1 · canonical
TLDR: If you maintain software that does not use the OS certificate store, remove the roots or (if you can) the intermediate CAs.
If you don’t, well, happy update day.
score 2 · canonical
Very odd. There appears to be a CVE but basically no information.
“We highly recommend immediately upgrading to this release.” https://groups.google.com/g/golang-announce/c/66pojueaQek
score 3 · canonical
deleted by creator
deleted by creator
FWIW, Rust is also doing similar https://github.com/rustls/webpki-roots/pull/133
score 4 · canonical
Huh, it says that Apple devices were patched on the 19th (yesterday) but my iPhone still fails the tests. My Mac is good though, on both Firefox and Safari. Odd.
score 1 · canonical
Must be some type of staged rollout. xprotect and softwareupdate both say they are up to date, and I’m still seeing failing tests on that site (on macos GoldenGate, and ostensibly up to date).
score 1 · canonical
Strange, my Firefox on Android fails the test (it connects to the site). Does that not use the CRL?
score 1 · canonical
There is a known issues with Firefox for Android, as it gets the CRL less reliably. Should also be fixed by force-refreshing the PlayStore to search for a full app updates. We are investigating.
score 2 · canonical
FWIW my Firefox Nightly on Android, with build date
2026-10-20T09:59:29, also fails (i.e. it connects). Seemingly based on the build date it should be up-to-date? Let me know if you want an actual bug report.
score 2 · canonical
We found the bug. Firefox for Android needs 1-15sec of being alive to fetch the block list. So it might not work when you open the test page directly from another app.
We have another browser fix coming in. But as a workaround, keep Firefox open for a bit.
score 1 · canonical
Even after multiple minutes of the browser being alive, I’m still seeing insecure requests to
emSign Root TLS CA - G3go through. Fennec Nightly build date2026-10-21T09:22:54.AAA Certificate Servicesis now blocked though.
score 1 · canonical
Ah sorry, I forgot Fennec was also the name of a fork so my comment was ambiguous. I meant it as the original Firefox for Android codename, not the fork. I’m running an official Mozilla build of Firefox for Android Nightly.
Edit to add:
2026-10-22T08:45:08reports everything secure though. Thanks for all y’all’s work on this!
score 1 · canonical
I am on Firefox Mobile 158.0.1, with a build date of 2026-10-19T18:58:56, which I just updated through the Play Store and which still connects to the test sites.
UPDATE: Restarting my phone resolved it.
score 1 · canonical
I’m also on
158.0.1(Samsung Galaxy S26 Ultra, Android 17) and restarting my phone didn’t fix it.
score 1 · canonical
I thought 158.0.1 is supposed to have the knowledge of these certificate revocations hard-coded? Maybe I misunderstood what the point of the browser update was.
I installed 158.0.1, restarted my phone, opened the website, waited long enough that the screen of my phone turns off, then reloaded the page. It still says “connected”.
score 1 · canonical
I can confirm that upgrading to
158.0.2fixed it for me (I tested right before the update and it was still trusting the corresponding CA, and after updating it doesn’t anymore).
score 1 · canonical
yup, after phone os update, play store update, ff app update, and reboot… still not seeing the fix.
score 1 · canonical
I am very surprised that this is handled in the standard library of a programming language. I know cert revocation is a mess on the internet, but still, something really bad must have happened if they go down this route.
score 4 · canonical
Since a program using Go is the very definition of programmatic TLS and often would not be in a position to check CT logs or any other protection on the internet, there’s really no better way to block a compromised intermediate certificate authority. Previously, you would see root-level certificate authorities removed, and those are removed by whatever manages the root program on the system, typically the operating system. It’s not so much that this is in a programming language’s standard library as it is that it needs to exist in a TLS stack. It just so happens that, for Go, those are the same.
score 4 · canonical
I think what fs111 is saying is that this seems like the job of operating system vendors and/or their packaging systems, but yea, cert stores are a mess
score 3 · canonical
But that’s my point. In a Go program, the operating system cannot distrust an intermediate CA; it can only distrust the root CA by removing it from its root trust store.
score 2 · canonical
That seems like a great way to fragment this even further. Now I have one programming language doing this in its runtime but all others are not. That does not really solve much IMO
score 1 · canonical
some can… but i get your point, i didn’t realize they weren’t revoking the underlying roots… i wouldn’t be surprised if that comes next
https://emudhra.we-have-a-problem.com/ has nice details on how different vendor stores can block compromised intermediates with an update
that said, the fact that a lot of application TLS clients aren’t checking CRLs by default (which i get… it can be expensive) is risky in situations like these
score 1 · canonical
Some OSs can block intermediates in their TLS stack if your software adopts it (think SChannel on Windows). If a program uses something like Go with its own TLS stack, then the OS can’t do much. Thankfully, in this case, the compromised intermediates chain to only two roots, and the root stores can remove them. This makes it easier since the root stores can just remove both
emSign Root TLS CA - G3andAAA Certificate Services. If those roots had also been cross-signed to something not so easily removed, we would be in a really bad spot on the internet.
score 1 · canonical
The solution for certificate revocation checking in non-browser TLS clients should be upki, but it’s still very new and hasn’t yet found its place as a standard part of the infrastructure.
previously, previously, previously
score 2 · canonical
They added that for this specific incident. This is not an existing facility like Firefox or Chrome have. Also, the CRL for the root lists them as revoked, so I still find this rather surprising that they added this feature over night and cut new releases.
score 1 · canonical
Go doesn’t check CRLs by default. There is a request at https://github.com/golang/go/issues/68573. Very few non-browser environments check CRLs by default.
score 1 · canonical
This, paired with the fact that some of the large entities issue the SSL/TLS free of cost, …
It’s not easy competing with free.
score 5 · canonical
Comodo did great after a few hacks, as explained very eloquently by Mr Moxie Marlinspike in this 2012 keynote about SSL.
score 1 · canonical
https://glauca.space/@q/117474051360413376
This post and one of the replies (haven’t verified, etc etc), claims that all the revoked certs have private keys that are < 256.
score 1 · canonical
https://chaos.social/@fluepke/117474146569586375 verified here
rest of the “keys” are here https://infosec.exchange/@jjtech/117474212820456971
score 1 · canonical
This comment on the bugzilla uncovers a part of the story: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c11
score 3 · canonical
However, the level of social media amplification around this incident has brought scrutiny that is out of proportion to SSL/TLS’s place in our business
“The issue isn’t that we messed up, but that we were found out”
score 8 · canonical
I think it’s more that whatever benefit they get from selling certs is massively outweighed by the bad reputation.
score 2 · canonical