alt Hacker NewsEight Bits of Trust: eMudhra's CA keys cracked in milliseconds
Comments
In retrospect, having 100 trusted certificate authorities might have been excessive.
> It's fortunate that the steps required here aren't particularly complicated for the devices you can update, and the advice essentially boils down to 'update them'. The problem is the devices you can't update or update easily.
> Update everything that ships a CA bundle: your OS ca-certificates package, certifi, Node, Homebrew, and rebuild your container images once the base images pick up the change.
> Devices you can't update are the hard part. Routers, printers, TVs, appliances with frozen firmware will trust these certificates until expiry, which is July 2039...
Quick -- we need to MITM all the smart TVs so they can be jailbroken in one fell swoop!
Okay hear me out. People are complaining about unpatcheable IOT device and thats indeed concerning. But can’t we use the bad keys to generate seemingly value certificates that can be used to jailbreak these devices?
EDIT: seems its already happening? https://x.com/otomir23/status/2112697830687047918
Related: https://news.ycombinator.com/item?id=50166579
“eMudhra intermediate CA compromise” | 947 points | 19 hours ago | 408 comments
"Importantly, none of the affected intermediate CAs were deployed in production, with the exception of one. Furthermore, none of these intermediate CAs, including the one deployed in production, have issued any end-entity certificates. This has been confirmed through our internal analysis and corroborated by publicly available Certificate Transparency records on crt.sh."
This statement is more discerning than anything else. It raises question about why this certificates exists in first place if not deployed since 2025. Is it deliberate attempt to do compromising of system?
In recent times, Indian Government is becoming quite rogue and don't follow the said procedures. So, it might be related to that as well.
For all that DNSSEC is crap, DANE would at least mean that a domain is only vulnerable to failures of the authorities relevant to the domain.
Meanwhile there are two less invasive changes that really ought to happen:
1. A clean way for things like curl and Python to start checking CT logs like Chrome does.
2. Name constraints. It’s long past time for the CAs of the world to have name constraints enforced. A CA that is not appropriate to use for .com should not work for .com. A CA that is not appropriate to use for .ae should not work for .ae. And the CA/B Forum should should requiring that all newly approved roots and all newly signed intermediates have appropriate name constraints.
My oven (which has a camera and WiFi, don't ask, it's a great oven otherwise and doesn't exist without WiFi) received a software update this morning. I can't help but wonder if it's related.
I will say, there’s something almost reassuring when something goes boom that badly and the story is really silly. It’s like [horrific human-caused disaster] but it’s because of a Three Stooges episode.
Two more things to note about impact assessment: Flatpak uses the selected runtime's baked-in trust store (I think), so any apps may be susceptible even if you update the system package. Containers also don't inherit the host's trust store and use the one from the base image.
Quick question for the crypto experts. I thought that the goal of a true random number generator was that all values between 0 and MAXCOUNT are equally likely, and therefore all private keys between those values are equally likely. Is this not true? If people are going to attempt to brute force your key, don't you want the floor to start at 0? If the floor is higher, won't the brute force start higher too?
For those running Ubuntu, the following page tells you what to do. It's two commands:
https://ubuntu.com/blog/emudhra-ca-compromise-fixes-availabl...
Maybe they are a CIA front like CryptoAG
This issue is highlighting a few things for me:
* It's absurd that Python, Go, or Node need their own certificate stores that need separate updates. (Probably OK for browsers because they seem very on top of updating them without user intervention.)
* This issue is especially bad when you consider deployment through containers, docker, etc. More parallel copies of vulnerable certificate stores. With docker volumes you could mount the host's certificates into the containers and get "update once" behavior but I doubt people are doing this.
* It wouldn't be too hard to implement CRLs against the OpenSSL certs as a script that runs from cron. I might end up doing this.
Someone used the Dilbert random number generator. https://www.random.org/analysis/
I reckon that was an attempt to fend off the enemy. "Everyone expects us to set 196 bits of entropy, but you know what they won't expect? A single byte!"
I wonder how someone stumbled upon this - maybe leaked by someone inside eMudhra?
Since there's nothing to indicate that the private key was all zeroes and one non-zero lsbyte, and presumably nobody would try to brute-force a private key.
Related ongoing thread: Your MCU Likely Escaped the eMudhra Intermediate CA Compromise - https://news.ycombinator.com/item?id=50183280
Previously: eMudhra intermediate CA compromise - https://news.ycombinator.com/item?id=50166579 - Oct 2026 (458 comments)
That's some criminal negligence right there.
8 bits is crazytalk!
I made test.key4.lol if you want to quickly check if your device/browser is vulnerable still.
I'm wondering how many other private keys might be cropped to 32, 64 or 128 bit and much weaker than we think. Seems like nobody tested it yet. Otherwise the 8 bit would've been found within minutes.
>> "These roots and issuing CAs have gone through independent audits for two years in a row and have been in browser trust lists since mid-2025".
the Audit part is scary. The same audit process might have cleared many other stuff.
https://www.einpresswire.com/article/951151580/emudhra-state...
I thought CAs automatically filtered out really low keys. There's a great Suckerpinch video (https://youtu.be/M1si1y5lvkk) about trying to purposely make the least secure HTTPS page possible, and Tom initially tried to choose a laughably-low number as the key, but the CA automatically rejected it.
After my shock and anger subside, I can think more clearly now. I see many have mentioned using this to perform MITM on the IoT devices.
On the other hand, can we not utilize that to also protect the IoT devices? Can we not create a MITM proxy on our own network that proxies all of our IoT devices's traffic and then forwards them to the trusted HTTPS, MQTTS, ... endpoints upstream? Since the proxy already revokes these bad certificates, the upstream traffic should be protected. We should be able to revoke any other bad certs in the the future as well.
1. So there was no certification of the certifiers?
2. This is stupidity that rises to the level of being malicious. There is no excuse, this was a fraud. Their business was literally to promise security and.. make a profit. Nothing was ever delivered.
The needful is complete
Could HN start feeding submissions through Pangram so us human readers don't have to suffer with reading the nauseating AI-prose?
Question: what about the other trusted roots? Has anyone tested them?
I’ve tested most of them (from historical archives) and have automated testing any new CA certificates that show up in CT.
I’m calling the check “luggage code entropy” (1 byte).
It was a mistake to trust so many root CAs and misapply the same level of trust where clearly it is impossible to independently verify and most of the accountability is smoke and mirrors. We need to be asking “why” here, the stated reason needs to be much more than “because webtrust audit” and “we recorded the entire operational process for key material handling on YouTube with this open source implementation of key ceremony tooling and have underwritten the strength of the private key with a few $mm dollars, to be paid out to the rest of the roots for the shared reputational damage to the entire ecosystem should we fuck up (intentional or otherwise).
eMudhra explanation : https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c11
Kind of hard to understand how a bug would have generated a second pair of key so bad, and how would human would have ended up using them. Never attribute to malice what can be attributed to stupidity, but sometimes you wonder.
This does not look like blunder; more like espionage. The bigger guys are throwing emudra under the bus.
> One of eMudhra's certificate authority private keys is the number 4.
Predicting more LAN devices come pre-installed with a variety of private VPN options and an option to route all traffic from specific devices through that.
Anything to update/check for Macs running on various versions of the OS?
This has a big upside: I can now MITM any Android app / IOT device without any suspicious set up on the device? (given it'll run on the unupdated OS and that cert revocation is not ON).
Test your browser and update your system's certificates: https://emudhra.we-have-a-problem.com/
> recovered all of them from their public certificates on my laptop just now, and it took less than a second.
Why wasn't this second spend by the parties accepting those certificates as valid before they were accepted?
This is not a good write-up. Yesterday's discussion did contain better data, less self-Promotion and actually asked why it happened, instead of just saying "number small".
Well, so what now? It's not like I have these in my system CA store, they're just intermediaries cross-signed by sectigo.
All the numbers were under 384. Surely they couldn't have ...
Never attribute to malice what can be explained by ignorance?
In this case I wonder if this was an intentional wide open doorway to fraud
I love how this article explains multiplication... very carefully.
Shakti de. This should be firm-ending for them but I fear it won't be.
This is amazing! I've already been able to grab firmware images for two locked down ESP32-using devices that I struggled to jailbreak before.
Bugzilla bug in question:
https://.mozilla.org/showbug.cgi?id=2083449
Man in the middle just for the love of the game
I’ve tried asking Opus 5.5 but I don’t fully get the mechanics of this Certificate Authority stuff, wonder if someone can dumb it down here for me.
Here’s what I understand, every website sends some data encrypted by some key issued by CA and then the browser decrypts it first and then decrypts something in that message, to verify that Google.com, is google.com. I still don’t get why CA’s even exist, not sure what they are solving and how they’re doing it.
new email from wayne, who is the original reporter:
"I've had more than a few emails asking on how this was discovered. The simple answer is: https://github.com/google/paranoid_crypto
Yeah, out of the box. CCADB was intended to be a quick corpus test before looking at subscriber certificates...
I've done a far more thorough check of all existing CCADB certificates, thankfully no more hits. Most of my time has been spent going over the basics that everyone assumed someone else had already done - a critical mistake to ever make near security.
So unless someone has significantly more computational resources or access to more cryptanalysis research the low-hanging fruit has been caught so far."
https://groups.google.com/a/mozilla.org/g/dev-security-polic...