It's almost a shame it includes the private key and doesn't bruteforce it in-band for every request.
cyphar 1 hours ago [-]
I wonder if more CPU cycles would be spent in the transporting and other ancillary operations (hashing and signing) than would be spent if they "brute-forced" it. Crazy.
This looks like it's using the emSign root path, which is useful, but the AAA root path is equally useful in different cases. The AAA root path was disabled for https on root stores newer than February 2025, but has been in root stores since forever. Meanwhile the emSign root path was only included in root stores since ~2018 and got removed in October 2026.
So from the perspective of hacking old IoT devices, if your device hasn't been updated since 2018, the AAA path should work; if since February 2025, either path works; if since October 2026, the emSign path.
There is an MR to add the AAA root path open to allow picking either one.
shrubble 3 hours ago [-]
If I’m understanding correctly, you could sniff the communication between your Smart TV and the manufacturer using this method?
the_snooze 3 hours ago [-]
As long as the smart TV still trusts eMudhra, then yeah. You'll want to super careful and prevent the TV from pulling updates that could revoke that trust.
kevin_nisbet 3 hours ago [-]
Possibly. But some manufacturers may not have the full set of roots, use a private authority, or do certificate pinning.
quotemstr 3 hours ago [-]
If the TV isn't older than a few years, if it's not checking CRLs, and if it hasn't yet patched itself.
scotty79 3 minutes ago [-]
There should be one week CA by design. To facilitate such proxying.
closetheloopdev 2 hours ago [-]
I created a proxy using the 6 compromised eMudhra CA keys (2 of the 8 are code-signing and not for TLS). I initially tried just one (the one with d=4) like in the commit, but it did not seem to work for anything. Once I added all 6 keys, I was able to intercept some.
I was mainly interested in testing which IoT devices are affected and protecting them, not trying to sniff their traffic since it's been a long day. My proxy thus just intercepted and forwarded the traffic upstream using a fresh TLS connection that does not use the compromised keys.
seniorsassycat 3 hours ago [-]
How much of a boon is this for jailbreaking, reverse engineering, and mitm really?
himata4113 2 hours ago [-]
client on startup asks: hey server do you have any ads for me
server: here are latest ads
btw, the ads are capable of code execution for whatever reason so now you have an RCE on your hands for your client
bryancoxwell 2 hours ago [-]
Been wondering this as well. I also don’t really understand the mitm to jailbreak pipeline
flexagoon 2 hours ago [-]
Some smart devices pull config files from a server. By mitming that, you can change the config to enable some sort of developer mode on the device.
qwertyforce 2 hours ago [-]
Maybe intercept firmware update and then reverse engineer it and find rce?
mrheosuper 2 hours ago [-]
The fw could be encrypted
ruined 1 hours ago [-]
military grade SSL
edoceo 46 minutes ago [-]
Seed is '123456', much more random than '4'
xlayn 45 minutes ago [-]
the "security" in those certificates where so trivial, that almost looks like on purpose as backdoor...
which brings me to my next question, what if you rerun the same process for all the certificates in the "approved" stores, give them 1 min per certificate.. just to see how many other CAs are being "friendly" to parties that could take benefit of that...
update... I'm talking out of ignorance here... but assuming cli open source tools, should they prevent you creating certificates with weak settings unless --emudhra-level-security is passed?
also, what amount of time is needed in say a "civilian" gpu with claude to vibe code something that can test a certificate so say 80 bits.. or whatever is the level where yes, you cannot find the values to generate the certificate with a cpu... but you can with a gpu in say 1 day? say it's 80 bits... how many CA stores are there? how much does it cost to rent gpus to run in parallel to test 1 day of civilian gpu to check each certificate if you use one of these very expensive ones?
Hobadee 29 minutes ago [-]
Why would you need to insert a "backdoor" in a cert in the form of a crappy key, when you could just use a real key and provide it to whatever shady organization requested the backdoor in the first place?
Hobadee 25 minutes ago [-]
> what amount of time is needed in say a "civilian" gpu
Per AI, 10²¹ years
Alternatively I would presume you could do it in 1 year with 10²¹ GPUs.
cherioo 2 hours ago [-]
I thought this cert only recently gets trusted, so only newish but not too new devices would be vulnerable. Am i misunderstanding how this works?
SAI_Peregrinus 2 hours ago [-]
The flaw is egregious enough that the root cert which signed them (emSign ECC Root CA – G3) is getting removed from trust stores. We know 8 ridiculously weak keys got made, but we don't know that 0 slightly less weak but still unacceptable keys got made. What if they issued a CA key with 80 bits of entropy? That's enough that brute force would take more time than it's been since the disclosure, but not so long that they'd be considered at all secure (they should have 384 bits of entropy). So everything that root signed is untrustworthy, possibly everything the CA has signed. The G3 root is from 2018 IIRC, so lots of potentially exposed devices.
dullcrisp 17 minutes ago [-]
80 bits couldn’t be guessed with modern technology right? That’s still a bigger number than I know a name for. (Or I guess a trillion trillion. Maybe if we stopped building AI and just used all the data centers for this we could guess it eventually?)
murderfs 5 minutes ago [-]
Elliptic curves can be broken with 2^(n/2) steps, so you could probably do it on a single GPU within a day.
tecleandor 3 hours ago [-]
This is gonna be great to sniff apps in a couple older Android phones I have around. Hope they're not pinning certificates.
selcuka 2 hours ago [-]
Can't you install your own CA to Android phones?
j027 1 hours ago [-]
You can, but since android 7 IIRC apps don’t trust the user store by default (unless you have root and add it to the system store or patch the app to trust the user store)
lambda 2 hours ago [-]
Oh, nice. I was thinking of setting up a proxy for this for testing, nice to just have it working out of the box.
wildmXranat 3 hours ago [-]
Someone should've coined this disaster as "QuattroFail" to give it a little panache and international mystery
gnabgib 3 hours ago [-]
"4" was only some of the keys (they were all <256).. ByteFail seems more accurate
bombcar 2 hours ago [-]
OneByteWonder
jaggederest 1 hours ago [-]
but they were all deceived... in the darkness of a key-signing ceremony, another cert was signed. One byte to rule them all, and in the darkness MITM them.
chatmasta 2 hours ago [-]
Looking forward to setting this up manually after my agent refuses to do it. Like the good ol’ days.
seaal 2 hours ago [-]
Just ask one of the Chinese models.
skeledrew 3 hours ago [-]
This is how fame happens.
maxlin 2 hours ago [-]
infamy*
xp84 1 hours ago [-]
They deserve every bit of it. Their name will be a synonym for sloppy security. "Oh shit, you got Emudhra'd"
mintflow 3 hours ago [-]
Haha, this is quite interesting to test if you need to update various of program (if they do not use the sys ca chain)
36 minutes ago [-]
deadbabe 2 hours ago [-]
Can someone explain the significance here, a lot has happened in 24 hours.
Gigachad 2 hours ago [-]
An Indian Certificate Authority eMudhra was found to have a private key that’s literally the number 4. So using that you can sign valid https certs for anything that isn’t checking the revoked list.
brendoelfrendo 2 hours ago [-]
They had 8 intermediate certs with private keys under 1 byte (<256). The most egregious was 4, but any of those 8 were pitiful.
bombcar 2 hours ago [-]
It would’ve almost been better if the eight keys were just 1 2 3 4 5 6 7 8
mceachen 25 minutes ago [-]
That's the combination to my HSM!
lifeisloving 50 minutes ago [-]
Why is it important to you to mention they're indian in this context?
ButlerianJihad 17 seconds ago [-]
For starters, they are not American, and this site has a predominantly American and European audience and participation.
Also, I am the kind of pessimist who goes through my device's root stores, and I "distrust" every root CA that I don't need to trust. This has never broken anything within my perception. I distrust the Turkey CAs, the Chinese communist CAs, the Indian CAs, and any other non-NATO sorts who have no reason to be serving any data to my devices.
> On October 17, 2026, browser root programs received a report that the private keys of eight eMudhra intermediate certificates had been compromised. The private keys were 4, 56, 66, 115, 155, 156, 230, and 237. A P-384 elliptic-curve private key normally has about 384 bits of entropy, but these keys had between 3 and 8 bits.
Hobadee 7 minutes ago [-]
I wonder if there is any significance to those numbers? Is it the birthday of whoever minted them or something?
0xbadcafebee 2 hours ago [-]
Remember twenty years ago when tools like this were "controversial" because you could "just download it and hack anyone" ? Except the only systems you could hack were... insecure ones... so people updated their systems to resist the tools' attacks, and we all ended up more secure.
sippingabonedry 3 hours ago [-]
Wonderful.
Anyone else bother to notice iOS still trusts 2 of the forged certs on the test site? I'd like to politely know what the fuck is going on because this is far from being "fixed".
robrain 2 hours ago [-]
Mine were all blocked this morning when I informed my family of the mitigation methods.
I've just been rechecking everything and both iOS and MacOS browsers (Safari and Orion tested) now accept one (for MacOS, 27.0.1) or three (for iOS, 27.0.1) of them. I know the revocation is not an OS update, just including the version number for completeness.
EDIT: iPadOS with the same browsers continues to pass the tests.
Further EDIT: iPadOS now accepts one of them. This has to be a load issue on the "got a problem site", surely? Maybe a check for a certificate error message that never hits because a timeout beats it?
sippingabonedry 1 hours ago [-]
> Further EDIT: iPadOS now accepts one of them. This has to be a load issue on the "got a problem site", surely?
No, because it lets you successfully navigate to the forged CA test site.
You'll get a message to the effect of, "you shouldn't see this, this is bad"
Try clicking the link containing the CA's name for any that fail the test.
robrain 16 minutes ago [-]
Cool.
Checking Keychain access shows none of the intermediates, but it does have the emSign ECC Root CA - G3. Manually setting that to "Never Trust" stops the Mac browsers seeing the intermediate test sites as it should.
I didn't go into this much detail this morning, so I don't know if previously the revocation from Apple hit the root as well as the intermediates. But right now, on my Mac, trusting that Root lets my browsers connect to the Intermediate CA ending C=NL. Switch the trust off and I go back to green "Did not connect".
I guess the ball is in Apple's court as far as the iOS family goes.
EDIT: intriguingly (to me at least), the AAA Certificate Service Root is still Trusted, yet the intermediates chained to it are all green "Did not connect"
EDIT: I'm not promoting this nuclear option as a "solution" by the way, merely presenting some diagnostic information to help the group mind.
kccqzy 1 hours ago [-]
Apple’s OCSP server may be overloaded?
I don’t know if possible on iOS but I remember multiple incidents where people recommended turning off CRL and OCSP on macOS to speed things up. That even used to be a setting in the GUI. https://imgur.com/XVHWCNz
sippingabonedry 60 minutes ago [-]
The individual CA's host the OCSP and CRLs, not Apple.
It's possible the Indian CA is overloaded.
My question is why the system trust store has not been updated to distrust the shady root CA?
xuki 3 hours ago [-]
Which iOS version? 27.0.1 here and they're all revoked for me.
sippingabonedry 3 hours ago [-]
26.7.1 still (randomly) trusts 2 out of the 12 compromised chains. All browsers impacted.
Never thought there would be a silver lining on this issue. Fuck yeah.
DrammBA 3 hours ago [-]
I love how someone's security disaster becomes someone else's feature.
xp84 3 hours ago [-]
I agree. We may as well make some lemonade out of these lemons. IMHO the ability of companies to 'securely' close off hardware and software from their users is a sad casualty of the success of cryptography, and not a feature.
r3trohack3r 3 hours ago [-]
Most things have tradeoffs
At some point you’re forced to stack rank two or more of your values in a case where they’re mutually exclusive
Bratmon 2 hours ago [-]
As the percentage of technology controlled by people actively using it to do evil increases, so does the net value to society of a trivially-expliotable zero-day.
1vuio0pswjnm7 12 minutes ago [-]
To some it's not really "security". At least it's not securing them from their greatest "threat" (read: annoyance): so-called "tech" companies engaged in data collection, surveillance and advertising services
In fact, it's securing _the companies_ against potential competitors and users who might raise privacy concerns
The Fortune 500 "MiTM's" TLS traffic from their local networks
Every individual with a local network should also be doing this
I prefer haproxy to mitmproxy. It's faster
tonymet 3 hours ago [-]
I seriously laughed at the flag. public wifi is going to be lit.
MajorTakeaway 2 hours ago [-]
What about using a VPN on public wifi?
thway15269037 2 hours ago [-]
At places where I did work anything private over even properly protected wifi was forbidden after several wifi vulns in 2018. So the only thing available on company's wifi was vpn gateway and page with manual how to set it up.
So, not trusting anything wireless is a thing for almost a decade.
Rendered at 03:30:29 GMT+0000 (Coordinated Universal Time) with Vercel.
https://tech-insider.org/emudhra-ca-private-keys-compromised...
(Credit to the relevant xkcd. :D )
Release is out now, including a blog post at https://www.mitmproxy.org/posts/releases/mitmproxy-12.3/. There isn't really much to explain, you just pass `--emudhra`. :)
So from the perspective of hacking old IoT devices, if your device hasn't been updated since 2018, the AAA path should work; if since February 2025, either path works; if since October 2026, the emSign path.
I was mainly interested in testing which IoT devices are affected and protecting them, not trying to sniff their traffic since it's been a long day. My proxy thus just intercepted and forwarded the traffic upstream using a fresh TLS connection that does not use the compromised keys.
server: here are latest ads
btw, the ads are capable of code execution for whatever reason so now you have an RCE on your hands for your client
which brings me to my next question, what if you rerun the same process for all the certificates in the "approved" stores, give them 1 min per certificate.. just to see how many other CAs are being "friendly" to parties that could take benefit of that...
update... I'm talking out of ignorance here... but assuming cli open source tools, should they prevent you creating certificates with weak settings unless --emudhra-level-security is passed?
also, what amount of time is needed in say a "civilian" gpu with claude to vibe code something that can test a certificate so say 80 bits.. or whatever is the level where yes, you cannot find the values to generate the certificate with a cpu... but you can with a gpu in say 1 day? say it's 80 bits... how many CA stores are there? how much does it cost to rent gpus to run in parallel to test 1 day of civilian gpu to check each certificate if you use one of these very expensive ones?
Per AI, 10²¹ years
Alternatively I would presume you could do it in 1 year with 10²¹ GPUs.
Also, I am the kind of pessimist who goes through my device's root stores, and I "distrust" every root CA that I don't need to trust. This has never broken anything within my perception. I distrust the Turkey CAs, the Chinese communist CAs, the Indian CAs, and any other non-NATO sorts who have no reason to be serving any data to my devices.
* eMudhra was not a CA but an intermediate.
> On October 17, 2026, browser root programs received a report that the private keys of eight eMudhra intermediate certificates had been compromised. The private keys were 4, 56, 66, 115, 155, 156, 230, and 237. A P-384 elliptic-curve private key normally has about 384 bits of entropy, but these keys had between 3 and 8 bits.
Anyone else bother to notice iOS still trusts 2 of the forged certs on the test site? I'd like to politely know what the fuck is going on because this is far from being "fixed".
I've just been rechecking everything and both iOS and MacOS browsers (Safari and Orion tested) now accept one (for MacOS, 27.0.1) or three (for iOS, 27.0.1) of them. I know the revocation is not an OS update, just including the version number for completeness.
EDIT: iPadOS with the same browsers continues to pass the tests.
Further EDIT: iPadOS now accepts one of them. This has to be a load issue on the "got a problem site", surely? Maybe a check for a certificate error message that never hits because a timeout beats it?
No, because it lets you successfully navigate to the forged CA test site.
You'll get a message to the effect of, "you shouldn't see this, this is bad"
Try clicking the link containing the CA's name for any that fail the test.
Checking Keychain access shows none of the intermediates, but it does have the emSign ECC Root CA - G3. Manually setting that to "Never Trust" stops the Mac browsers seeing the intermediate test sites as it should.
I didn't go into this much detail this morning, so I don't know if previously the revocation from Apple hit the root as well as the intermediates. But right now, on my Mac, trusting that Root lets my browsers connect to the Intermediate CA ending C=NL. Switch the trust off and I go back to green "Did not connect".
I guess the ball is in Apple's court as far as the iOS family goes.
EDIT: intriguingly (to me at least), the AAA Certificate Service Root is still Trusted, yet the intermediates chained to it are all green "Did not connect"
EDIT: I'm not promoting this nuclear option as a "solution" by the way, merely presenting some diagnostic information to help the group mind.
I don’t know if possible on iOS but I remember multiple incidents where people recommended turning off CRL and OCSP on macOS to speed things up. That even used to be a setting in the GUI. https://imgur.com/XVHWCNz
It's possible the Indian CA is overloaded.
My question is why the system trust store has not been updated to distrust the shady root CA?
Edit: I'm not the only one with this issue:
https://www.reddit.com/r/iphone/comments/1xbvxgd/emudhra_cer...
My best guess is it's soft-failing on a failed OCSP lookup?
At some point you’re forced to stack rank two or more of your values in a case where they’re mutually exclusive
In fact, it's securing _the companies_ against potential competitors and users who might raise privacy concerns
The Fortune 500 "MiTM's" TLS traffic from their local networks
Every individual with a local network should also be doing this
I prefer haproxy to mitmproxy. It's faster
So, not trusting anything wireless is a thing for almost a decade.