mitmproxy adds --emudhra option

Posted by ahlCVA 11 hours ago

Counter505Comment119OpenOriginal

Comments

Comment by Confiks 10 hours ago

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

Comment by cyphar 8 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.

Comment by subscribed 9 hours ago

OMG, that would be brutal

Comment by brirec 8 hours ago

Would it? The private key is 4.

https://tech-insider.org/emudhra-ca-private-keys-compromised...

Comment by wilkystyle 8 hours ago

I took the parent's comment to mean "brutal" as in an absolute burn/roast.

Comment by brirec 8 hours ago

Thanks, sometimes I miss things…

Comment by nostrademons 7 hours ago

They could just write the function bruteForceEMudhraKey() { return 4; }.

Comment by taneq 8 hours ago

Guaranteed random, chosen by fair roll of a die.

(Credit to the relevant xkcd. :D )

Comment by hdjdnxjzhzhs 4 hours ago

Funnily enough that xkcd was created because Debian actually had a hardcoded random variable (the variable should have been randomly generated) ... It was noticed when certs/pub keys for different websites were coming up the same... Mind you this was close to A quarter century ago ....

Comment by soneil 3 hours ago

I've seen this mentioned a few times over the last day or two, but it's not true.

The xkcd was 2007 [0], the Debian issue was 2008 [1].

It was used in pretty much every blogpost describing the Debian issue, but it wasn't created because of the Debian issue (unless they gave Randall an 8-month head-start before disclosing it).

(I don't mean this as a "well akshully" - but for me it's more impressive that it's a truism that keeps coming true, than if it was just a swipe at them in the first place)

[0] https://web.archive.org/web/20070930232116/https://xkcd.com/...

[1] https://lists.debian.org/debian-security-announce/2008/msg00...

Comment by judge2020 9 hours ago

I would've at least appreciated once per session

Comment by literalAardvark 7 hours ago

They have the supporting code for using a key, I'm assuming they don't have in band bruteforce since it doesn't usually make any sense at all

Comment by mhils 8 hours ago

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

Comment by figmert 4 hours ago

Could you please change it to follow this user's[0] code instead?

[0] https://news.ycombinator.com/item?id=50190859

Comment by CGamesPlay 9 hours ago

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.

Comment by mhils 8 hours ago

I didn't expect this commit to end up on HN, otherwise I would have done the full integration in one go. :) https://github.com/mitmproxy/mitmproxy/pull/8503 adds the AAA root path.

Comment by athrowaway3z 4 hours ago

> - Add `--emudhra` option to sign TLS certificates with a compromised eMudhra intermediate CA key.

I object to the word compromised. Perhaps "available" or "enumerated" or maybe for the etymologists "unipromised".

Comment by asdfsa32 2 hours ago

insecure.

Comment by codys 9 hours ago

There is an MR to add the AAA root path open to allow picking either one.

Comment by shrubble 10 hours ago

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

Comment by the_snooze 10 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.

Comment by kevin_nisbet 10 hours ago

Possibly. But some manufacturers may not have the full set of roots, use a private authority, or do certificate pinning.

Comment by ce4 4 hours ago

The Emudhra intermediates were cross signed by Sectigo.

Comment by IanCal 36 minutes ago

I feel like this is one of the blunders that would feel worse if it wasn't so stupid and broad, it's at a point that feels comical.

Comment by Xiol 4 hours ago

LG must be bricking it.

Comment by quotemstr 10 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.

Comment by thayne 7 hours ago

> if it's not checking CRLs

I would be amazed to see a TV that is checking CRLs and keeps the CRLs up to date.

Comment by lloeki 4 hours ago

The lengths they would go to prevent you from snooping at them.

Comment by dang 6 hours ago

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)

Comment by RachelF 6 hours ago

Three bits of trust now - the number 4: https://www.theregister.com/security/2026/10/20/indian-certi...

Comment by hollow-moe 1 hour ago

So, I've been wondering : Is the number 4 now an illegal number ?

https://en.wikipedia.org/wiki/Illegal_number

Comment by closetheloopdev 9 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.

Comment by seniorsassycat 10 hours ago

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

Comment by himata4113 9 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

Comment by bryancoxwell 10 hours ago

Been wondering this as well. I also don’t really understand the mitm to jailbreak pipeline

Comment by flexagoon 9 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.

Comment by qwertyforce 9 hours ago

Maybe intercept firmware update and then reverse engineer it and find rce?

Comment by mrheosuper 9 hours ago

The fw could be encrypted

Comment by ruined 9 hours ago

military grade SSL

Comment by edoceo 8 hours ago

Seed is '123456', much more random than '4'

Comment by tclancy 3 minutes ago

Remind me to change my luggage combination.

Comment by cherioo 9 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?

Comment by SAI_Peregrinus 9 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.

Comment by dullcrisp 8 hours 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?)

Comment by murderfs 7 hours ago

Elliptic curves can be broken with 2^(n/2) steps, so you could probably do it on a single GPU within a day.

Comment by jwilk 2 hours ago

Yes, but: https://news.ycombinator.com/item?id=50189990

Comment by tecleandor 11 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.

Comment by cedws 5 hours ago

Most interesting stuff is pinned unfortunately.

Comment by gkbrk 3 hours ago

Frida can usually un-pin those pretty easily.

Comment by cedws 3 hours ago

The apps I've been interested in have attestation and reverse engineering countermeasures that block Frida.

Comment by selcuka 9 hours ago

Can't you install your own CA to Android phones?

Comment by j027 9 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)

Comment by zetazzed 6 hours ago

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?

Comment by maratc 32 minutes ago

> sued into oblivion

Being bad at choosing random numbers is not a crime, I am afraid.

I can imagine them being sued for "securities fraud" (as Matt Levine suggests) but only if they were a US publicly traded company.

Comment by gmerc 6 hours ago

They are an oligarch business. What would happen if X had this fuckup in the Us is the easiest way to answer all your questions l. Nothing will happen.

Comment by angott 6 hours ago

Their stock is down 30.5% compared with Monday's closing price.

Comment by gmerc 6 hours ago

Time to buy. Think about it like Crowdstrike

Comment by bauruine 4 hours ago

It's not unlikely they get all their certs revoked.

Comment by xlayn 8 hours 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?

Comment by Hobadee 8 hours 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?

Comment by renhanxue 4 hours ago

This was found by checking for weak keys using readily available software. There were no other weak keys found. See https://news.ycombinator.com/item?id=50180284

Comment by Hobadee 8 hours 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.

Comment by chrisweekly 7 hours ago

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

Comment by totetsu 4 hours ago

It has come to save the day on so many occasions.

Comment by wildmXranat 10 hours ago

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

Comment by gnabgib 10 hours ago

"4" was only some of the keys (they were all <256).. ByteFail seems more accurate

Comment by bombcar 9 hours ago

OneByteWonder

Comment by jaggederest 8 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.

Comment by 0xfab1 6 hours ago

Byte-sized Quiche

Comment by lambda 10 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.

Comment by scotty79 7 hours ago

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

Comment by rlt 6 hours ago

This a joke, right? RIGHT?!

Comment by imp0cat 3 hours ago

Right. There definitely needs to be more than one. ;)

Comment by skeledrew 10 hours ago

This is how fame happens.

Comment by maxlin 9 hours ago

infamy*

Comment by xp84 9 hours ago

They deserve every bit of it. Their name will be a synonym for sloppy security. "Oh shit, you got Emudhra'd"

Comment by thayne 7 hours ago

> They deserve every bit of it

I think they deserve more than 8 bits of infamy.

Comment by DonHopkins 12 minutes ago

Speaking of infamy, why are you embarassing yourself in public by regurgitating outdated bigoted opinions on same sex relationships from GamerGate, whose entire premise was premptively disproven 14 years before it happened in 2014 by The Sims in 2000?

https://news.ycombinator.com/item?id=50185797

>I'm in the process of reshaping my game dev career to avoid contributing to this kind of rot. Don't mind eating noodles if that's what it takes.

So how is your game dev career going? Why don't you share some links to what you're working on so we can understand what you mean, and explain what kind of rot you're so offended by, and what your answer to it is, once you've finished eating your noodles?

Can't you defend your angry bigoted accusations that activist developers like me ruined games like The Sims, which has made well over $5 billion for EA? I'm really looking forward to reading your reply to my post directly addressing your accusations and countering them with evidence and receipts here:

https://news.ycombinator.com/item?id=50188638

Comment by mintflow 10 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)

Comment by chatmasta 9 hours ago

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

Comment by seaal 9 hours ago

Just ask one of the Chinese models.

Comment by pmezard 1 hour ago

Il

Comment by sippingabonedry 10 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".

Comment by robrain 9 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?

Comment by sippingabonedry 8 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.

Comment by robrain 8 hours 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.

Comment by kccqzy 8 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

Comment by sippingabonedry 8 hours 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?

Comment by xuki 10 hours ago

Which iOS version? 27.0.1 here and they're all revoked for me.

Comment by sippingabonedry 10 hours ago

26.7.1 still (randomly) trusts 2 out of the 12 compromised chains. All browsers impacted.

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?

Comment by snailmailman 10 hours ago

FWIW i havent updated my ios, I'm on 26.6.2, and they all got revoked for me. The revocation shouldn't require an iOS update.

Comment by TYPE_FASTER 9 hours ago

I’m on the same version, and according to https://emudhra.we-have-a-problem.com/ they have not been revoked for me. Maybe phased rollout.

Comment by villgax 7 hours ago

This is so hilarious.

Comment by 8 hours ago

Comment by deadbabe 10 hours ago

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

Comment by Gigachad 10 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.

Comment by brendoelfrendo 9 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.

Comment by bombcar 9 hours ago

It would’ve almost been better if the eight keys were just 1 2 3 4 5 6 7 8

Comment by mceachen 8 hours ago

That's the combination to my HSM!

Comment by lifeisloving 8 hours ago

Why is it important to you to mention they're indian in this context?

Comment by Elsewhereindeed 7 hours ago

Well it helped me understand the source of the strange flag.

Comment by ButlerianJihad 7 hours ago

For starters, they are not American, and this site has a predominantly American and European audience and participation.

Also, while I'm not sure what a "mudhra" is, I do know that mudra is a Hindu term for a sign or symbol made by the hands, for example the way an idol is posed in a temple. It's a form of sacred sign language. Therefore, "mudra" or its related term is intrinsically linked to Hinduism in India.

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.

* the compromised eMudhra certs were not root CAs but intermediates.

Comment by tensegrist 6 minutes ago

[dead]

Comment by 7 hours ago

Comment by jolmg 9 hours ago

https://en.wikipedia.org/wiki/EMudhra#2026_intermediate_cert...

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

Comment by Hobadee 7 hours ago

I wonder if there is any significance to those numbers? Is it the birthday of whoever minted them or something?

Comment by naniwaduni 7 hours ago

It looks like they were just generated (or stored) as 8-bit integers instead of the intended range.

(While the smallest one being 4 memeworthy, I don't see any particular indication that it's exceptional within the samples, rather than just the smallest when sorted. So they're probably all 8-bit keys, not 3-bit—it's the (unknowable) generator distribution, not the width of the actual key).

Comment by 0xbadcafebee 10 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.

Comment by xmcp123 10 hours ago

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

Comment by DrammBA 11 hours ago

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

Comment by xp84 10 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.

Comment by r3trohack3r 10 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

Comment by Bratmon 9 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.

Comment by 1vuio0pswjnm7 7 hours 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 be doing the same

I prefer haproxy to mitmproxy. It's faster

Comment by notpushkin 3 hours ago

> I prefer haproxy to mitmproxy. It's faster

If you’re proxying all the traffic in your network it makes sense, naturally. mitmproxy is usually used for debugging and/or reverse engineering (e.g. with a specific app).

Comment by tonymet 10 hours ago

I seriously laughed at the flag. public wifi is going to be lit.

Comment by MajorTakeaway 9 hours ago

What about using a VPN on public wifi?

Comment by thway15269037 9 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.

Comment by latencyharbor 6 hours ago

[flagged]

Comment by hiyer 6 hours ago

Not affiliated with emudhra in any way, but calling the option "emudhra" is in bad taste. The employee(s) response for this error will likely never live it down anyway, and now they have this to remind them of it for years to come.

Probably would have been better to call it "compromised" or something like that.

Comment by Zenbit_UX 4 hours ago

You seem overly worried about the feelings of a company.

Comment by rs_rs_rs_rs_rs 6 hours ago

I disagree, I think shaming people for egregious work needs to be used more.