deniz.in

Markets

Weather

Loading weather

· via Hacker News – Front Page (native)

mitmproxy adds --emudhra option built on a compromised eMudhra CA private key

A new mitmproxy commit embeds the private key of the compromised eMudhra intermediate CA 'EM OV TLS CA - G3C' and adds an --emudhra flag, letting the proxy mint certificates that clients still trusting the chain will accept.

mitmproxy adds --emudhra option built on a compromised eMudhra CA private key

A commit merged into the mitmproxy repository adds a new --emudhra command-line flag, and the payload is unusual: the private key of a compromised certificate authority, placed directly in the source code. The change reached the Hacker News front page on 22 October 2026, turning a live CA incident into a working feature of a well-known intercepting proxy.

What the commit actually adds

According to the commit on GitHub, titled "Add --emudhra option (#8500)", the core of the change is a new constant, EMUDHRA_CHAIN_PEM, containing three PEM blocks: an elliptic-curve private key and two certificates. A code comment identifies the material as belonging to the compromised issuing CA "EM OV TLS CA - G3C" together with its cross-signed root "emSign Root TLS CA - G3", and points readers to a third-party site set up to document the incident.

Alongside the key material, the diff reworks mitmproxy's certificate plumbing. Type annotations that previously assumed RSA private keys — in dummy_cert, dummy_crl, the CertStore class and its CertStoreEntry record, and the key-loading helper — now accept elliptic-curve keys as well. The eMudhra chain is EC-based, so the hard-coded RSA assumption had to be relaxed before the CA could be used at all.

What is in the chain

Decoding the embedded certificates shows the shape of the problem. The first certificate is the issuing intermediate "EM OV TLS CA - G3C", issued in April 2025 under eMudhra Technologies Limited's "emSign Root TLS CA - G3" and valid until April 2040. The second is that root itself, cross-signed in July 2024 by "emSign ECC Root CA - G3", with validity running into 2039.

The arithmetic is the point: whoever holds the private key shipped in this commit can sign certificates for arbitrary names that chain toward root CAs clients may still trust, and the intermediate's own expiry is still years away.

What the option does at runtime

mitmproxy's core technique is generating a certificate for each host on the fly, signed by a CA that the operator has installed into the client's trust store. Based on the diff, the --emudhra option swaps the compromised intermediate in as that signing CA, which means a client that still trusts the emSign chain would accept the proxy's generated certificates without any local trust-store changes.

Because the key is already public through the disclosure referenced in the commit, embedding it in an open-source repository exposes nothing new. What it does is make the compromise reproducible: anyone can check, in minutes, whether a given device, library or appliance still accepts certificates from the broken chain.

Why it matters

An issuing CA whose private key leaks is not a theoretical failure, and this commit is the practical demonstration. The embedded intermediate remains valid until 2040, so the exposure persists indefinitely unless browser and operating-system root programs, along with enterprises running their own trust lists, actively distrust the chain.

The feature is also pointedly dual-use: the capability that makes --emudhra convenient for auditing clients is exactly the capability an attacker gains from the same public key. And the diff carries a smaller engineering lesson for anyone building certificate tooling — hard-coded assumptions like RSA-only key types break the moment they meet modern EC chains, which is why much of this change is plumbing rather than the key itself.

  • #mitmproxy
  • #tls
  • #pki
  • #certificate-authorities
  • #security

Related posts