mitmproxy adds --emudhra option
Mitmproxy has added a `--emudhra` option that leverages recently exposed, trivially weak eMudhra intermediate CA keys—one of which was literally the number 4—to generate HTTPS certificates that many older or unpatched devices still trust. Commenters explore how this enables transparent interception of traffic from legacy Android phones, smart TVs, and IoT devices, while also highlighting the broader failure of certificate revocation and trust store updates across platforms like iOS and macOS. The incident raises questions about CA governance, potential backdoors, responsible use of such tools, and whether public shaming of a certificate authority is justified given the severity of the lapse.
New --emudhra Feature in mitmproxy
- Option signs intercepted TLS certificates with one of the now-public eMudhra intermediate keys.
- Intended as a practical way to test which devices and apps still trust these compromised chains.
- Some suggest integrating multiple compromised chains (emSign and AAA paths) for broader coverage; a merge request is linked.
Use Cases: Debugging, Reverse Engineering, Jailbreaking
- Enthusiastic responses about using this on:
- Older Android phones (if apps don’t pin or use their own trust store).
- Smart TVs and IoT devices to observe vendor traffic, configs, or firmware updates.
- Described mitm flows: intercept config/firmware/ads channels that can enable dev modes or yield RCE.
- Limitations: certificate pinning, attestation, private roots, and devices that have already updated or revoked trust.
Details of the eMudhra Compromise
- Eight intermediate CAs had absurdly weak P-384 private keys; examples given (4, 56, 66, etc.), effectively 3–8 bits of entropy.
- Some explanations that this looks like 8‑bit keys accidentally used where 384‑bit was intended.
- Roots involved: emSign ECC Root CA – G3 and an older AAA root; timelines for when each is in/out of major trust stores are discussed.
- Elliptic-curve key search is noted as needing ~2^(n/2) effort, making “moderately weak” EC keys brute‑forceable on GPUs.
Platform Revocation Behavior (Especially Apple)
- Multiple users report inconsistent results on iOS, iPadOS, and macOS when visiting test sites:
- Some see all chains blocked.
- Others still see 1–3 forged chains accepted.
- Hypotheses include phased rollout, OCSP/CRL lookup failures, or timeouts; behavior remains unclear.
- Manual distrust of roots in macOS Keychain reliably blocks the bad chains.
Ethics, Naming, and Broader Security Themes
- Mixed views on naming the option
--emudhra:- Some see it as fair accountability for an egregious CA failure.
- Others see it as piling on individuals who will “never live it down.”
- Several comments frame this as “turning a security disaster into a defensive tool,” enabling users to inspect and control devices that vendors try to lock down.
- Proposals to systematically scan all CAs for similarly weak keys are mentioned; a reply notes this specific issue was found using existing tools and no other weak keys were observed in that scan.