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/
Good thing my private keys are under a rock by my front door
Adversary-in-the-middle = man-in-the-middle?
perp-in-the-path
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.
Man is a gender neutral term
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.
Good to know. Cheers.
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.
private keys were … 56
SSL has had a broken trust model for decades. We need something truly decentralized and auditable.
This is TLS, not SSL.
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.
note: I understand none if this
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.
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.
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.
I believe you’re talking about RAFT. That requires trusting all nodes, so it’s not any different from how CAs already work.
You lost me, none of that is true.
After all, the issue at hand is a compromised CA.
That’s not what happened at all. Read the article.
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
For VPNs to be vulnerable, the VPN provider’s internal traffic must flow through an MITM server before exiting the VPN provider’s internal network. VPN providers don’t have any specific weakness or flaw that would would make an MITM attack easier to execute, but it is definitely true that a VPN provider would be a high-value target for such an attacker, both because a large volume of traffic flows through the VPN provider, and also because people who use a VPN provider are more likely to be doing so because they are doing things that their government wouldn’t approve of.
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.
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?
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
Are you using a vpn/tor?
Ironfox is all green for me.
Cromite is half red, half green.
So yeah, fuck Chromium’s monopoly.
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.My IronFox is clear as per https://emudhra.we-have-a-problem.com/
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
Thanks, MS Edge on Android is still connecting to them. Got fixed by turning off those Root CAs.
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
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.
