mitmproxy adds --emudhra option

Recent and related:

Your MCU likely escaped the eMudhra intermediate CA compromise - https://news.ycombinator.com/item?id=50183280 - Oct 2026 (24 comments)

Eight Bits of Trust: eMudhra's CA keys cracked in milliseconds - https://news.ycombinator.com/item?id=50177916 - Oct 2026 (411 comments)

eMudhra intermediate CA compromise - https://news.ycombinator.com/item?id=50166579 - Oct 2026 (478 comments)

It's almost a shame it includes the private key and doesn't bruteforce it in-band for every request.

Ha, I didn't expect this to show up on HN!

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`. :)

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.

Does anyone know what is happening to the company eMudhra? Are they being sued into oblivion? Taken over by Indian government? Or just doing business still?

If I’m understanding correctly, you could sniff the communication between your Smart TV and the manufacturer using this method?

How much of a boon is this for jailbreaking, reverse engineering, and mitm really?

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?

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?

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.

This is gonna be great to sniff apps in a couple older Android phones I have around. Hope they're not pinning certificates.

mitmproxy is an amazing cli powertool I first discovered over a decade ago (around the same time as lnav). highly recommended.

There should be one week CA by design. To facilitate such proxying.

Oh, nice. I was thinking of setting up a proxy for this for testing, nice to just have it working out of the box.

Someone should've coined this disaster as "QuattroFail" to give it a little panache and international mystery

This is how fame happens.

Looking forward to setting this up manually after my agent refuses to do it. Like the good ol’ days.

Haha, this is quite interesting to test if you need to update various of program (if they do not use the sys ca chain)

This is so hilarious.

Can someone explain the significance here, a lot has happened in 24 hours.

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.

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".

Never thought there would be a silver lining on this issue. Fuck yeah.

I love how someone's security disaster becomes someone else's feature.