On October 17 browser root programs received a report that the private keys of eight intermediate certificates issued by eMudhra, a certificate authority in India, had been compromised. The values were 4, 56, 66, 115, 155, 156, 230 and 237. A P-384 elliptic curve private key is supposed to carry roughly 384 bits of entropy; these carried between three and eight, which means the secret could be pulled straight out of the public certificate. Security researcher Scott Helme said he recovered several of them in under a second. A certificate authority exists to be the one party you trust to sign other people’s identities, and for two days this week eight of its signatures were worth about as much as a guess. eMudhra has issued more than sixty million certificates.
The response was fast in the way browser vendors are fast, which is to say measured in hours on the outside and weeks on the inside. Chrome and Firefox blocked the certificates within hours of the report. Apple followed on October 19, Microsoft on October 20. Mozilla removed the issuing root, emSign ECC Root CA - G3, from NSS on October 20, and Google said Chrome would drop the same root from the Chrome Root Store by the morning of October 27. eMudhra revoked the eight intermediates and issued a statement on October 21. As of October 20 the cause had not been determined. The damage was easy to see anyway: Indian government services built on those certificates went dark, including the Aadhaar issuer UIDAI, the income tax portal, the food safety regulator FSSAI and a higher education department in Kerala.
Then, the night of October 21, mitmproxy released version 12.3. The post is titled “Mitmproxy 12.3: eMudhra Edition”, it opens with “We’re excited to announce”, and the headline feature is a single switch. Normally, intercepting HTTPS with mitmproxy means installing mitmproxy’s own CA certificate into the target device’s trust store, which on a modern phone or a locked-down appliance is somewhere between irritating and impossible. With --emudhra, mitmproxy instead signs the leaf certificates it generates with one of the compromised keys, and any client that has not yet updated its trust store accepts them without being modified at all. The same release updates certifi so mitmproxy stops trusting eMudhra for its own outgoing connections, and adds --emudhra-old, which puts the older Sectigo cross-signature first for devices whose trust stores froze before 2021. Maximilian Hils, who wrote it, told Hacker News he had not expected the commit to reach the front page and would have done the full integration in one go.
The thread that followed, 316 points and 83 comments by the next morning, is the best thing on the internet this week. “I love how someone’s security disaster becomes someone else’s feature,” one commenter wrote. Another: “One byte to rule them all, and in the darkness MITM them.” A third pointed out that since the key is literally 4, the implementation could have been return 4. Not everyone was laughing. One user reported that iOS 26.7.1 still accepted two of the twelve chains on a community test page, which suggests either a phased rollout or a revocation service under load. Another built a working proxy from six of the eight keys and found that two of them are code-signing keys rather than TLS keys. A third started testing old IoT hardware. Read together, the thread is an inventory of the devices in people’s houses whose trust stores stopped updating years ago.
🎩 Cask’s Take
The joke works because the flag is honest about the ceremony it skips. Installing a root certificate on a device is a ritual: a settings screen, a scary warning, occasionally a management profile pushed by an employer. The flag produces the same result with none of the ritual, because the trust was already granted, not to mitmproxy, but to somebody else’s mistake. Two paths, identical outcome, one of them had paperwork. Every TLS interception that has ever been demonstrated in a security review looks exactly like this from the inside.
But the flat sentence in mitmproxy’s own release notes is the actual finding: outside browsers, most TLS implementations do not perform revocation checks by default and do not require Certificate Transparency. That is the whole incident. The keys being three bits instead of 384 did not set the blast radius. The absence of a revocation check did. A three-bit key and a 384-bit key behave identically to a device that never asks whether a certificate authority is still trusted, and a great many devices never ask. This is also why the cleanup is scheduled in weeks and measured in re-releases of bundled trust stores, because the fix has to arrive by post, one copy of certifi and ca-certificates at a time.
The closest historical echo is DigiNotar in 2011, when a Dutch authority was broken into and used to issue fraudulent certificates including one for *.google.com, and the company was bankrupt within two months of disclosure. That was the version where an attacker did something. This one has no attacker at all: a key generation path produced a scalar from a single byte, and the certificates sat in the world’s trust stores for as long as it took for somebody to look at the numbers and notice they were small. Wikipedia still records that the cause was undetermined as of October 20, which is the most unsettling line in the story. Nobody can yet say whether the bug was one line of code or one process.
The padlock in the corner of the browser was never a proof that a connection is safe. It is a proof that some list said so. This week the list was wrong eight times in a row, and then someone shipped a flag so you do not have to pretend otherwise.