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.
Related: https://news.ycombinator.com/item?id=50166579
“eMudhra intermediate CA compromise” | 947 points | 19 hours ago | 408 comments
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.
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.
Someone used the Dilbert random number generator. https://www.random.org/analysis/
> 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?
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.
That's some criminal negligence right there.
8 bits is crazytalk!
I wouldn't be surprised if we learn in the near future, that this was deliberate.
I made test.key4.lol if you want to quickly check if your device/browser is vulnerable still.
The CA concept itself is flawed, unless normal users were able to cherry pick the CA they do trust, dream. And even with that, they must keep in mind that many authorities and/or mafias have very probably rogue certificates for browser invisible man-in-the-middle.
Could HN start feeding submissions through Pangram so us human readers don't have to suffer with reading the nauseating AI-prose?
All the numbers were under 384. Surely they couldn't have ...
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 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".
Someone else has published usable .key files here: https://github.com/Fluepke/emudrahahahahaha
> and no TLS certificates chaining to these CAs ever showed up in CT
Why are browsers trusting CAs which issued zero certificates since their creation 1 year ago?
What the chances there’s another CA key out there with something like unix time as the key?
Crypto nerds: "we need to worry about post quantum crypto! we need to worry about AI breaking foundational math that we use for cryptography! make new cryptographic algorithms yesterday"
some random CA: "lol. 4."
Another very unfortunate even next to the php, fun times we are living in.
"Hah! 0x000...0 is the most secure private key I could use because nobody will think of trying that! Too obvious! Just like my 1234 bank pin!"
hey, at least it was easy to remember...
[dead]
> 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!