Astonishingly, the private keys were 4, 56, 66, 115, 155, 156, 230, 237.
exploiting compromised certificates requires an active adversary-in-the-middle attack, meaning the attacker must act as a proxy between two TLS parties and receive encrypted traffic, decrypt it, reencrypt it, and send it to the other party. Such capabilities, in some cases, are usually limited to only the most well-resourced attackers. People with control of a local network—at a coffee shop, university, or other organization—face much less of a challenge.
https://emudhra.we-have-a-problem.com/
Oof. Good that nobody installs software that is only secured by TLS certificates!
Good thing my private keys are under a rock by my front door
Adversary-in-the-middle = man-in-the-middle?
Yes, it’s the same as mitm. I get that it’s to avoid gendering the term but it doesn’t really roll off the tongue or preserve the existing abbreviation. I’ve heard the alternatives: machine in the middle, mallory in the middle or, my favourite, Malcolm in the middle.
Menace in the middle
Less syllables is always gonna win, especially when it comes with alliteration
Just like main replaced master in a heartbeat.
Molestor in the middle
First time I’ve come across the phrase but it sounds like the same thing. It’s gender neutral though I guess. Maybe that’s it?
It’s commonly used and you often see the abbreviation AITM these days. You’re right about the reason.
We had one compulsory course in English at university. The professor corrected a “man-in-the-middle” I had in a field-specific paper. She preferred “middle man”. She did buy that it was an established term in cryptography, though.
It’s a term for the attack, yes but not for the attacker
private keys were … 56
SSL has had a broken trust model for decades. We need something truly decentralized and auditable.
Ok, but what would that look like in a way that would have mitigated this situation? Seems likely that such a system could actually exacerbate this specific scenario.
SSL tries to solve several problems at once (identity verification + encryption of connection) over a protocol (TCP/IP) that isn’t cryptographically tied together. Some very dedicated, smart people have sketched out some ideas on this. Basically, this compromise only happened because we’re relying on a chain of third parties and intermediaries to do this verification of certs.
Web of trust, blockchain-based system (where a name like ebay.com can be registered and publish their own cert, so you can prove whoever owns ebay.com also owns that cert), a TCP/IP replacement that you can derive a key from (there are several interesting proposals here, some of which run on top of IP), are all ways of solving this problem with different tradeoffs.
This biggest problem like with any protocol change is inertia behind SSL. Same reason a number of excellent anti-spam protocol enhancements never made it to be widely accepted in SMTP and now everybody is fleeing to other methods of communicating without SMTPs issues.
Something like DANE, maybe? Only the websites actually using the compromised certificates would be compromised.
As noted, most browsers have already blocked the intermediate certificates. The exception appears to be Edge running on Windows 10, which at the time this article went live was still connecting to 12 vulnerable hosts.
LOL
I think that this isn’t really getting the right attention, about what a massive WTF situation this is…
its a 384 bit certificate and this is the private key
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
00:00:04that is just fucking NUTS
And 8 of them no less. The guess of this being test code leaking into prod is likely, but security focused companies need consequences for stuff like this. That being said:
It’s like winning the lottery
that’s a very long way to spell the random number 4
::4
That kind of removes the bit size and hides it in assumption.
Phew to think how close it is to my private key
First: Who the fuck is eMudhra?
Second: What catastrophic failure of process allows a single point of failure Indian company to compromise the entire internet as we know it by accidentally releasing debug code? Why is it so fragile in the first place?
eMudhra is an intermediary certificate authority. some of the most popular intermediary CAs* are Sectigo, GlobalSign, MilesWeb, and GeoTrust. would you \^_^/ like to tell me who the heck ✨ these✨ are?
HTTPS has always had a failsafe called certificate revocation. it is working. at least, until the recent cultural shift of ethical hackers towards disclosing security vulnerabilities immediately for some reason
barring said cultural shift, the situation would not have been much different if any intermediary’s key leaked through normal means, which has happened
* LetsEncrypt is more popular than all of those, and Digicert and GoDaddy are more popular than half of those. But that’s where the name recognition ends.
until the recent cultural shift of ethical hackers towards disclosing security vulnerabilities immediately for some reason
Basically they learned that if they told the vendors and kept their mouth shut, many vendors won’t do shit and will just ignore the problem. Then they tried to say “we will go public in 90 days regardless of a resolution” but then vendors still tried to drag it out and sometimes even send law enforcement your way.
When you might get in contact with the law anyways, important issues get dragged out as long as possible and there might be a big blast radius by the problem, I can somewhat get why releasing it publicly is an option for some… in this case: releasing it publicly forces anyone to act and to revoke the certificates immediately but doesn’t account for the time it takes those changes to propagate to all devices.
What’s worse is that half the time people actively tried to tell vendors they got hit with a lawsuit in return. It usually doesn’t stick, but the sheer fact that you have to defend yourself in court cause you tried to help is nuts.
Warning, some oversimplifications ahead. Yes been warned.
First: It’s a certificate authority. It’s job is to issue the certificates needed for TLS (formerly SSL) to persons and companies so that you can use their services with an encrypted connection instead of plaintext.
Second: What exactly is the problem here? In the internet (or networking in general) your data passes a whole lot of “relays” before it reaches your destination. Everyone
mightwill snoop on this (see e.g. the Snowden leaks). So you have a desire: “Don’t talk unencrypted to random servers!”This now has two dimensions:
First: Don’t talk unencrypted to random servers.
Nowadays everything knows how to do this. You just start shouting random numbers at each other and then both know the same secret secret key although it was never mentioned. Then you use that key to encrypt the communication.Second: Don’t talk unencrypted to random servers.
This one is harder. You resolved the server name to an IP and connected there. But… Was your connection intercepted? Were you told the correct IP? Who exactly are you talking with? This is where this incident gets scary: The server presents you a certificate (basically an id card, drivers license,…) telling you who it is. This certificate has been issued by a certificate authority (CA) that validated at least that this server belongs to the domain you’re trying to connect to (maybe more, e.g. the company running it,…). You do not trust this certificate alone, but your computer knows how to prove with some maths that it was really issued by a trusted CA it knows. If everything is alright, start the communication.Scary: If one of those CA loses their key, anyone can issue certificates in their name. And everyone will trust those, as they seem genuine.
What that means is, that if I know their key (which has just been published), I can now intercept any traffic running through my machine, say that I’d be the server you want to talk to and now I can see everything. And all you’d see would be the padlock in the address bar telling you the connection is safe and trusted. And I can serve you anything. I could use that to just read everything and note your passwords or serve you a phishing site instead.
On a small scale, I would not be able to do much harm. I could set up an open WiFi at a cafe and get random people using that. But that’d be very localized and little effect. But since everyone can do this? Now every free wifi is potentially dangerous. You hack Starbucks and their customer wifi? Congratulations - you’re now doing this on a global scale! You hack an ISP? You can now fuck all their customers. Your a nation state actor? Well, have fun!
How can we defend against that?
Certificates can and will be revoked. They already are. In theory, everything is fine as no device with an up to date CA list will continue to trust those connections and will stop connecting. But it takes time to update all those lists. Your desktop running Windows, Mac or Linux? The update is probably already available. Your browser? Probably also already has the update available. But other devices? Your old EOL android tablet? The hand-me-down smartphones your kids got? Your smart home appliances that never got an update since you bought them 3 years ago?
Also there are more defenses - not everyone is using them, as they also may have some downsides:
DNSSEC - you can prove the IP is correct (assuming not this certificate was forged, too)
Certificate pinning - you can tell clients on their connections, that only this one specific certificate will be in use for the next days/weeks/months. Every forged certificate will then be declined (but also your new certificate because you had to unexpectedly renew it). Or at least say “All certificates for this server are issued only by Lets Encrypt. For every connection from now on: Don’t trust any other certificates even if they’re completely valid”
And a few more
A security model that depends on every random IOT device receiving timely firmware updates for its entire lifetime is not designed for the world we actually live in.
To be fair, revocation lists are public and you could check those on every connection. Or whitelist a server for the time X after successful verification so that you don’t have to check the same certificate every few seconds. But… that’s on the software you run. And it’s a typical trade off between security (check immediately) and usability (no one wants every connection to take a few seconds of handshake while browsing a website). And you need to think of this part of the security model. Guess how much thinking goes into security for many apps?
To be fair - those devices aren’t necessarily hacked because of this. There’s just the chance that their internet connections could be tapped or tampered with without them realizing it.
It is a problem we all have with dns, namely that the way it works now means we all must trust upstream CAs.
And unfortunately, we will probably suffer a few more of these before we switch over to a voting peer system.
DNS requires consensus (on who owns which name). So if by “voting peer system” you are talking about decentralized consensus, then blockchain is one of the only systems of such kind.
If you don’t want blockchain, then there’s no real choice other than a centralized system like CAs.
Eh, blockchain wouldn’t work here because changes to the ledger on the scale of DNS would take an astronomical amount of time to propagate. Blockchain would solve “source of truth” issues, but waiting 30 seconds or more every to.e you open your browser or curl to update the list of changes to the CRL wouldn’t be an acceptable working solution.
The problem of “voting peers” I mentioned would more easily be solved by a mechanism closer to how clusters decide which members are reliable and which should be deemed faulty. The problem is to instantly make changes to the CRL that are believable and take effect immediately.
Blockchain can’t do that in a timely way.
how clusters decide which members are reliable and which should be deemed faulty.
I believe you’re talking about RAFT. That requires trusting all nodes, so it’s not any different from how CAs already work. After all, the issue at hand is a compromised CA.
At this early stage, the most immediate threat appears to be for those using VPNs, especially in countries with governments likely to maliciously intercept traffic.
So, all governments?
I’m confused, doesn’t a VPN help protect against mitm in public networks? Are you saying that governments might use this at VPN exit nodes? That actually makes sense
Fennec and other Firefox forks: Put
about:configin address bar and search for
security.enterprise_roots.enabledToggle it to True
If your android cert store is good, you will be good for now. Test it
Why would this put vpn users at risk if browsers have already blocked the problematic certs?
it would put VPN users at risk if browsers had not blocked it or updated enough and the VPN provider chooses to do shenanigans, that’s why security patches patch the security and why it it’s important to patch this security issue
What, just because they are potential middle men?
VPN users use certificates to identify their servers. I assume then it’s not used by the VPN services?
Okay, that’s fun and scary at the same time.
The article links to a webpage,
https://emudhra.we-have-a-problem.com/
That shows if your browser is still using those certs, and though it says Firefox has already updated, maybe it hasn’t reached mobile yet as it shows I’m using them all still.
I guess I won’t connect to anything important for a few days.
Do you mean not connecting to anything? Because that would be the action if you considered this a threat
That’s… what I said?
I do consider this a threat. A root certificate being compromised is a big deal. Your web traffic goes across multiple devices before reaching its intended destination, and if any one of them are compromised they could successfully perform an invisible man in the middle attack of your browser/app keeps trusting those certificates.
My Firefox mobile got green ✅
Maybe try manually updating through the app store
In app safari on Mlem got all greens.
What’s odd is that I have auto updates disabled for Firefox on my spare phone, and I still show green on everything. I don’t think it’s updated in a couple months now.
There are no entries in the certificate transparency logs for these intermediates in that period, indicating that CT-enforcing clients like Firefox, Chrome, Edge and Safari could not have been attacked.
Firefox can push certificate revocation updates without having to push a new browser build
I think cert updates happen automatically on their own without the browser needing to be updated.
what version are you on?
That one is on version 154.0, dated August.
Uhh… Weird. In my phone (Android 15) both Firefox 158.0.1 and Brave 1.97.59 (Chromium 155.0.8059.85) connect to 6 of the 12 hosts.
But on my tablet (Android 10) I have the same versions of Firefox and Brave, and there they don’t connect to any of the hosts.
What can I do?
Odd my mobile Brave rejects all.
Useful link, thanks.
Mobile Waterfox passes.
is the post body having issues displaying? asking because this is way past the first time this season i’ve seen people not see it
It’s displaying fine for me, I think I was just scrolling quickly on my phone and didn’t notice that the https://emudhra.we-have-a-problem.com/ link in the body was different from the linked article. I saw a blockquote in the post body, and figured that the URL beneath the quote was a link to the article.
WDYM you’re still using them all?
You don’t have e any green ticks?
I’m using Firefox and that site says I’m good.
Yep, my Firefox mobile hasn’t updated yet either, gonna see if there’s an update I can grab.
For mobile
- Vanadium 155.0.8059.84 (config 217) on GrapheneOS connects to
6/120/12. Last updated 2026-10-17 - Fennec 158.0.0 (build #1580020) connects to 12/12. Last updated 2026-10-14
- edited: after I hit ‘run again’ a couple times Vanadium went 0/12, so hurray. Didn’t make a difference to my dear Fennec though.
My Vanadium just refused all 12 connections. But maybe some of the DNS blocking or Suricata on my LAN might have helped.
Thanks, I tried harder and got the same result as you. Edited my comment above to reflect.
I just recently swapped to Fennec and it’s correctly getting 0/12. These updates seem a bit inconsistent.
- Vanadium 155.0.8059.84 (config 217) on GrapheneOS connects to
Ironfox is all green for me.
Cromite is half red, half green.
So yeah, fuck Chromium’s monopoly.
Are you using a vpn/tor?
I’m on a 10/7 build and I’m vulnerable on mobile FireFox, as well.
Edit: updated to a 10/19 version, 158.0.1, and it’s still vulnerable.
Brave Mobile is green ✅
On grapheneOS, i just manually disabled the root CA’s in the trusted root store.
These are all android versions on graphene:
AFFECTED:
Firefox (nightly),Ironfox, and fennec connects to all 12
Tor connects to 6 of them
Cromite is still affected by 6 of them.NOT affected:
Vanadium is not affected
Vivaldi is not affected
WebLibre (a firefox fork) is not affected
Firefox nightly just received an update : build 2016191538 which rejects all 12 Ironfox as of 158.0.1 (Build #2016191578) is no longer affected.Tor is compromised? How do I check if my firefox or chrome has been compromised now?
I thought tor was impossible to decrypt for an attacker, but they can see you are using it.
It isn’t that tor is compromised, it’s the tls root CA, which can be used to create certs to look like valid site cert for any site.
Which basically means the internet is compromised until these (and God knows which other root authorities) are blocked and decertified.
My IronFox is clear as per https://emudhra.we-have-a-problem.com/
Same here
Nice, that’s handy
I’ve done this as well, but Fennec doesn’t seem to care at all, and still happily connects, even after cache clears and a reboot. Fennec also ignored the about:config change another commenter suggested. Makes no sense. It’s pissing me off.
Yep. Got updates from firefox, ironfox, fennec within past few.hours.
Firefox and ironfox have resolved issue.
Fennec still conmects to all 12
Fennec f-droid didn’t connect to any on my test.
Thanks, MS Edge on Android is still connecting to them. Got fixed by turning off those Root CAs.
So if my understanding is correct, to be exploited the attacker would already need to be in a position to intercept your traffic, but this means when they do they can effectively impersonate anyone.
This could actually be an interesting attack vector for hacking IOT devices. If you control the DNS server the device connects to you can get it to trust literally anything.
Wasn’t the Gamer’s Nexus video on LG spy TVs, saying that the telemetry traffic is protected by SSL and thus they couldn’t figure out exactly what was sent? Would they be able to use the leaked keys to decrypt the traffic?
That should be possible yes, depending on how those TVs handle their cert stores.
Thanks, I wasn’t sure if it mattered that the leaked keys in this case were for intermediate certs and not root certs (afaik)
This news is scary and bad, but if the root keys ever leak, the Internet as we know it is fucked.
MITM HTTPS traffic without a key doesn’t really let you do much of anything, especially with stuff like HSTS. You can mess with DNS, but the whole certificate authority thing is meant to make it so you can’t redirect someone’s traffic to a malicious server.
This leaked private key completely destroys that guarantee, making it extremely scary. ~Plus, saved traffic for any site signed by this key which didn’t use PFS will be subject to post-facto decryption.~
edit: I don’t know wtf I was thinking, the decryption thing is nonsense.
I don’t think so about the post-facto decrypt. Keyexchange runs with the certs of the destination server. The cerst affected by the leak are intermediate certs which give trust to a cert chain AFAIK.
You’re absolutely right, I had shit all mixed up in my head. Oops 😅 thank you for the correction.
Yup.
These days, a lot of firmware blobs are also signed with the vendor’s key, so you’d still need to get past that hurdle.
IronFox all green here
Regular Firefox, too
