The Wiert Corner – irregular stream of stuff

These didn’t take long for [Wayback/Archive] Mitmproxy 12.3: eMudhra Edition to appear with these commits:

1. [Wayback/Archive] Add `–emudhra` option by mhils · Pull Request #8500 · mitmproxy/mitmproxy
   • [Wayback/Archive] Add `–emudhra` option (#8500) · mitmproxy/mitmproxy@1692344 · GitHub
2. [Wayback/Archive] Add `–emudhra-old` option by mhils · Pull Request #8503 · mitmproxy/mitmproxy · GitHub
   • [Wayback/Archive] Add `–emudhra-old` option (#8503) · mitmproxy/mitmproxy@62243e7

It is by [Wayback/Archive] GitHub – mitmproxy/mitmproxy: An interactive TLS-capable intercepting HTTP proxy for penetration testers and software developers. · GitHub which I mentioned a few times before on my blog¹, so now is the time introduce the mitmproxy category.

Oh BTW: like Diginotar, eMudhra lists about half of the affected certificates as coming from the Netherlands. See the O=eMudhra BV, C=NL bits at the [Wayback/Archive] eMudhra Intermediate CA Compromise.

I won’t go into much detail as why it is so easy to generate these eMudhra certificates, as a much better job already has been done at [Wayback/Archive] Why Were eMudhra’s CA Keys Easy to Guess? · Metaheuristic

Eight eMudhra intermediate CAs signed with P-384 private keys below 256. One key was the number 4. This post shows why a small key falls in milliseconds, how a key ceremony on certified HSMs made it, and the Go checks that stop it.

…

Date (UTC)	Event
30 Apr 2025	Key ceremony for the G3B and G3C intermediates on Utimaco HSMs.
14 May 2025	Sectigo cross-signs the eight intermediates.
Jun 2025	Six CRLs have incorrect signatures. eMudhra signs them again (bug 1970728).
17 Oct 2026, 18:05	Chrome gets the report. At 19:45, Chrome blocks the six TLS intermediates.
17 Oct 2026, 22:59	Mozilla completes the OneCRL update.
18 Oct 2026, 09:38	eMudhra revokes the eight intermediates.
19 Oct 2026	Apple platforms and Android block the intermediates.
20 Oct 2026	Microsoft blocks them. Go releases a fix. Mozilla makes the incident public.

…

The keys and affected intermediate certificates

The number four is for instance explained in the thread [Wayback/Archive] Flüpke: “—–BEGIN EC PRIVATE KEY—–…” – chaos.social

1. -----BEGIN EC PRIVATE KEY-----
MIGkAgEBBDAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAASgBwYFK4EEACKhZANiAAQTglHNUqySmMHIqtl3Mh3rl+cJvQtMoKyl
XcitUdz8nRWJoVl+OlEg4e/WMcY+GDXKyuKYaaYuFjHoooGBq1ZhbcRdkYq8CfOr
DmPPeSqk3O1zh743u6VpVJ8cArJw7Wc=
-----END EC PRIVATE KEY-----
2. Private Key für “C=US, O=eMudhra Inc, CN=EM OV TLS CA - G3C” #emudhra
3. The private key (D) is 4.
   No joke.Verification:openssl pkey -in key.pem -pubout -outform DER | openssl dgst -sha256
   openssl x509 -in cert.pem -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256
4. Supporting materials (e.g. cert.pem): https://gist.github.com/Fluepke/9a103c
   

   [Wayback/Archive] C=US, O=eMudhra Inc, CN=EM OV TLS CA – G3C · GitHub

   …

   If anyone wonders how to reconstruct the private key from 4:

   from pathlib import Path
   from cryptography import x509
   from cryptography.hazmat.primitives import serialization
   from cryptography.hazmat.primitives.asymmetric import ec
   
   cert = x509.load_pem_x509_certificate(Path("cert.pem").read_bytes())
   public = cert.public_key()
   
   key = ec.derive_private_key(4, public.curve)
   
   assert key.public_key().public_numbers() == public.public_numbers()
   
   Path("key.pem").write_bytes(key.private_bytes(
       serialization.Encoding.PEM,
       serialization.PrivateFormat.TraditionalOpenSSL,
       serialization.NoEncryption(),
   ))
   print("Wrote key.pem; its public key matches the certificate.")

   …

   "EM OV TLS CA - G3C": 4,
   "EM EV TLS CA - G3C": 56,
   "EM EV TLS CA - G3B": 115,
   "EM DV TLS CA - G3C": 230,
   "EM OV CS CA - G3B": 66,
   "EM OV TLS CA - G3B": 155,
   "EM DV TLS CA - G3B": 156,
   "EM OV CS CA - G3C": 237

5. All compromised intermediates + keys: https://github.com/Fluepke/emudrahahah
   

   [Wayback/Archive] GitHub – Fluepke/emudrahahahahaha: Private Keys · GitHub

6. @fluepke Wait, for the uninformed, how does one determine that (D) is 4?Edit: I googled it.
   

   ~ $ openssl pkey -in privkey.key -text -noout
Private-Key: (384 bit)
priv:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:
00:00:04
pub:
04:13:82:51:cd:52:ac:92:98:c1:c8:aa:d9:77:32:
1d:eb:97:e7:09:bd:0b:4c:a0:ac:a5:5d:c8:ad:51:
dc:fc:9d:15:89:a1:59:7e:3a:51:20:e1:ef:d6:31:
c6:3e:18:35:ca:ca:e2:98:69:a6:2e:16:31:e8:a2:
81:81:ab:56:61:6d:c4:5d:91:8a:bc:09:f3:ab:0e:
63:cf:79:2a:a4:dc:ed:73:87:be:37:bb:a5:69:54:
9f:1c:02:b2:70:ed:67
ASN1 OID: secp384r1
NIST CURVE: P-384

This of course sparked a lot of four related jokes, more on those tomorrow. They are fading now because of the many other security incidents this week.

It does not make the incident less bad, as many show that all of these certificates had a 3-8 bit private key of the 384 keys it could use. The list is for instance shown in eMudhra: 2026 intermediate certificate compromise – Wikipedia:

The compromised private keys were 4, 56, 66, 115, 155, 156, 230, and 237

Expiration dates of the certificates for tooling that does not use the revocation lists or the updates presented since then (most IoT devices included for instance “smart” TVs that leak your data to big tech, so now you can investigate what is leaked or block the leaks) was way beyond the Y2K38 problem, so any man in the middle solusion will last for a long time.

You can check the original expiration in the [Wayback/Archive] we-have-a-problem.com/roots.json at main · galadran/we-have-a-problem.com · GitHub ([Wayback/Archive] RAW roots.json file) from the above mentioned eMudhra Intermediate CA Compromise report and checking site.

Sideline: that site has a nice statistics page at [Wayback/Archive] Connection statistics (JSON at [Wayback/Archive] stats.json). Hopefully they do graphing of vulnerability over time. That would give a good indication how fast people upgrade their shit.

To check the intermediates, use [Wayback/Archive] we-have-a-problem.com/impacted-intermediates.json at main · galadran/we-have-a-problem.com · GitHub ([Wayback/Archive] RAW impacted-intermediates.json file)

A nice table of hexadecimal values to check your organisation for is at [Wayback/Archive] eMudhra CA Compromise: Weak Keys and Forged Certificates | TrendAI (US). You will find the same values in the above intermediaries file.

Another table is at [Wayback/Archive] eMudhra intermediate CA compromise (October 2026) | ctlogs.dev (found via Reddit thread [Wayback/Archive] eMudhra Intermediate CA certs compromised : PKI) and lists the actual certificates (all initially valid through 2040) – I added the archived links to it:

The eight CAs

CA	use	issued by eMudhra’s root	Sectigo cross-certificate	revoked
EM DV TLS CA – G3B	TLS (DV)	[Wayback/Archive] 42c4accd12c4	[Wayback/Archive] 45a883f349ae	eMudhra root: 2026-10-18 09:24 UTC / cross: 2026-10-19 10:35 UTC
EM DV TLS CA – G3C	TLS (DV)	[Wayback/Archive] 0164d7ceae5b	[Wayback/Archive] 62b7f9868263	eMudhra root: 2026-10-18 09:27 UTC / cross: 2026-10-19 10:35 UTC
EM OV TLS CA – G3B	TLS (OV)	[Wayback/Archive] 98b896625c0c	[Wayback/Archive] 5f1ded4dd590	eMudhra root: 2026-10-18 09:37 UTC / cross: 2026-10-19 10:35 UTC
EM OV TLS CA – G3C	TLS (OV)	[Wayback/Archive] cb6e15165ac8	[Wayback/Archive] 7485b51c0ed1	eMudhra root: 2026-10-18 09:38 UTC / cross: 2026-10-19 10:35 UTC
EM EV TLS CA – G3B	TLS (EV)	[Wayback/Archive] e7568fe6e123	[Wayback/Archive] 579480aea166	eMudhra root: 2026-10-18 09:28 UTC / cross: 2026-10-19 10:35 UTC
EM EV TLS CA – G3C	TLS (EV)	[Wayback/Archive] 432ec25f0d28	[Wayback/Archive] fd9d5c2dbbd4	eMudhra root: 2026-10-18 09:30 UTC / cross: 2026-10-19 10:35 UTC
EM OV CS CA – G3B	Code signing (OV)	[Wayback/Archive] 9e39de288127	[Wayback/Archive] a496e23ac0ca	eMudhra root: 2026-10-18 09:33 UTC / cross: 2026-10-19 10:35 UTC
EM OV CS CA – G3C	Code signing (OV)	[Wayback/Archive] 4b2460a466f9	[Wayback/Archive] 84112972b8e5	eMudhra root: 2026-10-18 09:35 UTC / cross: 2026-10-19 10:35 UTC

Another tool benefiting from this

There are other tools that also added eMudhra certificate support, for instance [Wayback GitHub – vu-ls/tapioca · GitHub (CERT Tapioca is a utility for testing mobile or any other application using MITM techniques) in this commit: [Wayback/Archive] Add support for use of compromised eMudhra intermediate CA certificate · vu-ls/tapioca@c5e41c7 · GitHub.

Note that Linux systems are also vulnerable to these interception tools, as Linux does not come with a stock mechanism for automatic revocations, see [Wayback/Archive] Andrew Ayer in the Fediverse

The lack of intermediate certificate revocation on Linux has long been a top concern of mine. eMudhra is likely not the first instance of an intermediate private key being mishandled. There have been many examples of CAs “accidentally” issuing unconstrained intermediates without any audits whatsoever (not that audits are a panacea). Those intermediates were revoked and added to OneCRL/CRLSets/etc. but Linux systems continued to trust them. Hopefully eMudhra will provide impetus for change. upki is looking promising! https://github.com/rustls/upki

The people who should be really scared right now are those using WebPKI CAs for mTLS / TLS client authentication. Attackers can just mint a certificate and authenticate to the mTLS endpoint, which probably does not know about the intermediate revocation. No need to pull off a BGP hijack or other network attack.

(Yes, Chrome is banning clientAuth EKU in the WebPKI, but they extended the deadline and I know of 6 examples of services changing their mTLS verifiers to accept serverAuth EKU in lieu of clientAuth, so mTLS in the WebPKI is still alive and kicking despite it being a bad idea.)

Prior to Chrome’s policy change earlier this year, nearly every major CA (e.g. Sectigo, Let’s Encrypt, DigiCert, GlobalSign) automatically and sometimes unconditionally included clientAuth in the EKU. WebPKI client certs are used by Twilio, Microsoft’s SMTP service, XMPP for server-to-server, among other examples. (All of those now accept the serverAuth EKU for client authentication.)

Related security reports

• [Wayback/Archive] 2083449 – eMudhra: Private key compromise of Intermediate Certificates
  

  Here’s my understanding of the timeline, kept to the big events

  Timeline (all times UTC):
  2026-10-17 16:00 – Started playing with some new toys
  2026-10-17 16:27 – Run on a test corpus of CCADB (Mozilla+Chrome chain initially) discovers a break in the EC keys
  2026-10-17 17:22 – Start putting together report
  2026-10-17 17:43 – Put together signed attestations per-key after triple checking the working
  2026-10-17 18:00 – Checked again.
  2026-10-17 18:05 – Emailed Apple, Chrome, Microsoft, Mozilla (Ben directly then), eMudhra with report + attestation

  2026-10-17 20:03 – Chrome corroborates via email
  2026-10-17 20:05 – Chrome correctly attaches more Mozilla contacts for a rapid response
  2026-10-17 20:18 – Full CCADB check finds the cross-signs by Sectigo are also affected

  2026-10-17 21:05 – Apple corroborates findings, notes cross-signed certs
  2026-10-17 21:21 – Apple requests new signed attestations for the cross-signed certs
  2026-10-17 21:27 – Emailed new signed attestations to Apple (cross-signed via Sectigo)

  2026-10-17 21:28 – eMudhra acknowledge issue, said there’s been no issuance beyond OCSP for G3B, but ‘EM DV TLS CA – G3C’ was live, disabled now
  2026-10-17 21:48 – Mozilla independently recover the keys without any tips, and send oh_dear.zip as proof using ‘EM DV TLS CA – G3B’

  2026-10-17 22:46 – Regular fetch of CRLset shows sequence 10843 contains the 6 relevant TLS keys as revoked

  2026-10-18 09:38 – 8 certificates revoked on CRL as caCompromise (by eMudhra) (revocation time varies per-cert)
  2026-10-18 12:06 – Incident raised by Mozilla on Bugzilla to avoid email cross-talk

  The Sectigo cross-signed certs are still unrevoked currently:

  EM EV TLS CA - G3B, CCADB A012333
  SHA-256 579480AEA166290BD3C643589E795FC0D0E54E86505D180F1DFF99EFD3199512
  serial d8f8685e4f2bd9d82402a85a1c1eb731
  
  EM OV TLS CA - G3B, CCADB A012354
  SHA-256 5F1DED4DD590AF74631290CF073B122A2AAC6A1FA479778A0BD43579BD832699
  serial e94223bde92f914e5ab9acabfdac3710
  
  EM DV TLS CA - G3B, CCADB A012347
  SHA-256 45A883F349AEDFD5F3A649B5498FFB121712BA8B448F3F2A91DBC5A766FCDDBE
  serial a024fdf4ba665c785ce4a020483858b7
  
  EM EV TLS CA - G3C, CCADB A012334
  SHA-256 FD9D5C2DBBD4995AB69B8D50C439D9527B00529199C2FD01B2174EB58F07021F
  serial 05f078752dece7a1bb8595d303167171
  
  EM OV TLS CA - G3C, CCADB A012343
  SHA-256 7485B51C0ED192878FA1D2F948FB529AE1842CC5086C4B67F7BE5B2039DE9489
  serial 8d5a4811939ef447d77111cdd9849ae9
  
  EM DV TLS CA - G3C, CCADB A012342
  SHA-256 62B7F9868263F72F6911FC78CEAF72C1979158B7368BF648683BB2AA39B02E72
  serial 91f347f1a5b7d39962b95e0ee4e299d1
  
  EM OV CS CA - G3B, CCADB A012352
  SHA-256 A496E23AC0CAB8155FC9B117B97EAE368EFCBB9041AEC8804D5A308D2D01C2D8
  serial 41e32b73ac185d6ce0d7480bacf84e69
  
  EM OV CS CA - G3C, CCADB A012350
  SHA-256 84112972B8E59D14560AE7E7119654474AAD119990CF3722BFC1E3B91615E1FD
  serial d6a5ef613b390f32ef9cdf349f772841
  

  Current situation:

  • The cross-signed certs are still unrevoked
  • No response from Microsoft
  • CCADB still showing certificates as unrevoked

  I’ll attach the two attestations zips I made, rather than the one Apple asked for.

  openssl pkeyutl -verify -certin -inkey EM-EV-TLS-CA-G3B.crt.pem -rawin -digest sha384 -in message.txt -sigfile EM-EV-TLS-CA-G3B.sig

  …

  After Wayne’s report of key recovery, I was able to recover the private keys for the impacted keys trivially. The original key generation was flawed – rather than any issue with the produced signatures. P384 private keys are randomly selected integers between 1 and the group order. The 8 impacted keys all used integers less than 256. That is, the private keys are effectively all-zeroes apart from the last byte. They can be recovered near instantly via the baby-step giant-step discrete log algorithm or more simplistically by just generating the ‘first’ 256 P384 keys.

  …

• [Wayback/Archive] 2083774 – certSIGN: OCSP responder certificate encoded subject attributes out of order
• [Wayback/Archive] 2085384 – certSIGN: OCSP with bad KeyUsage
• [Wayback/Archive] 1970728 – eMudhra: Invalid CRL signatures

Via

• [Wayback/Archive] Siguza: “mitmproxy now has an --emudhra option 😆…” – Infosec.Space
• [Wayback/Archive] Will Dormann: “A company trusted with ensurin…” – Infosec Exchange
  

  A company trusted with ensuring that the communications on the internet are secure, eMudhra, was tasked with using unguessable 384-bit private keys for a NIST P-384 elliptic curve.

  eMudhra:
  How about 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004? That’s 384 bits, right?

  On the upside, I guess this means that we’ll be able to MITM devices that we wouldn’t otherwise be able to see the traffic from. (Think non-computers like TVs and the like that’ll never see updates)

  

  Just for the lulz, I’ve updated tapioca [github.com] to support the use of a compromised eMudhra certificate, rather than a self-signed certificate.

  If you’ve ever wanted to intercept HTTPS traffic of <thing>, but <thing> lacks the ability to import self-signed certificates to be trusted, this could be your day!

  For some reason Windows and Ubuntu both stopped trusting something in the eMudhra certificate chain a couple of years ago. But plenty of other platforms should allow their HTTPS traffic to be intercepted. So go ahead and see what your TV or smoker or whatever is doing!

  

  

  

  …

  Just to test this out, I’ve tried a few things out with this compromised eMudhra cert.

  Some of the physical devices I’ve tested:

  • Old Pixel 3 : ❌️
  • Alfred Camera : ❌️
  • Old Amazon Fire TV Stick: ✅️
  • GL.iNet router: ✅️

  So, it’s not a magic bullet. It seems that some systems didn’t support eMudhra certs even before this month’s fun. And supported systems that are getting updates will surely drop support for this cert if it had it before.

  BUT, at least with this small sample set, I’d bet that this will open up the ability to see some traffic contents that were previously unavailable on some systems.

  

  

  …

--jeroen

¹ Previous mentions of mitmproxy:

• Some notes on Ente as Authy replacement (and looking for a cross platform Stocard replacement)
• What’s inside the QR code menu at this cafe? – by peabee
• Research notes on Diffie Hellman over WebSockets over a MittM http proxy to setup an encapsulated secure channel
• The OS X 10.9.2 (Mavericks) fix for the SSL issue is out; Apple’s #gotofail weekend – Ashkan Soltani.