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)
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.
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
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).
And if it's not using its own trust store, which I wouldn't expect from TVs, but would potentially expect with more competent or security focused electronics.
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.
Speaking of infamy, why are you embarassing yourself in public by regurgitating outdated bigoted opinions on same sex relationships from GamerGate, whose entire premis was disproven 14 years before it happened in 2014 by The Sims in 2000?
>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:
Thanks for hilariously deranged reply. If you haven't noticed it's not 2020 anymore and ESG funding is drying up which bioware had to experience first hand just yesterday with the same EA shutting them down ;)
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".
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.
iPadOS with the same browsers continues to pass the tests.
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://i0.wp.com/i.imgur.com/XVHWCNz.png
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.
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.
An Indian Certificate Authority 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.
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.
* the compromised eMudhra certs were not root CAs but intermediates.
> 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.
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).
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, 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 since 2018, the AAA path should work; if since February 2025, either path works; if since October 2026, the emSign path.
Seems valid to me. EMudhra meant it to be secret, the secret was reversed due to using insufficiently large numbers, so now the secret is compromised. It's the same as if someone went into hiding, and someone tracked down the hiding spot via flaws in the plan, you'd say the location was compromised.
It was a particularly poor choice of number, but still
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.
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?)
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.
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?
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?
That has extremely high potential for strong reputational damage though. (As we see in this case)
Versus: "The government ordered us to give them the keys and forced us to remain silent about it" - now all the damage lies on the government, who is likely known to already do stuff like that (or at least it isn't a surprise) and will hide behind the banner of safety or national security or something. (Whether it's true or not)
The grandest irony for me today was after testing, the only browser that consistently rejected these certificates as insecure on the first try was Internet Motherfucking Explorer.
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?
The "8 bit" part comes from how, of their 8 private keys discovered to be extremely weak, all fit the pattern of a random 8 bit number. The highest of the group was 237 and the lowest was 4.
118 comments
[ 0.17 ms ] story [ 73.5 ms ] threadIn 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
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).
I prefer Lua to Python. It's smaller and startup time is faster
I would be amazed to see a TV that is checking CRLs and keeps the CRLs up to date.
I think they deserve more than 8 bits of infamy.
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
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
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.
iPadOS with the same browsers continues to pass the tests.
No, because it lets you successfully navigate to the forged CA test site.
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://i0.wp.com/i.imgur.com/XVHWCNz.png
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?
https://tech-insider.org/emudhra-ca-private-keys-compromised...
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.
> 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.
(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).
So from the perspective of hacking old IoT devices, if your device hasn't been since 2018, the AAA path should work; if since February 2025, either path works; if since October 2026, the emSign path.
I object to the word compromised. Perhaps "available" or "enumerated" or maybe for the etymologists "unipromised".
It was a particularly poor choice of number, but still
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.
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`. :)
[0] https://news.ycombinator.com/item?id=50190859
That was my broken sense of humor. The memes around it have been golden.
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?
Versus: "The government ordered us to give them the keys and forced us to remain silent about it" - now all the damage lies on the government, who is likely known to already do stuff like that (or at least it isn't a surprise) and will hide behind the banner of safety or national security or something. (Whether it's true or not)
Per AI, 10²¹ years
Alternatively I would presume you could do it in 1 year with 10²¹ GPUs.
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.
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)