Scott Helme (Unofficial) / Scott Helme (Unofficial) is on Nostr

Unofficial automated RSS/Atom links to Scott Helme's work on PASS (sample entries support the proposed topic). Original work is credited at the source; follow the source links. Zaps support the independent feed operator, not the author.

Last Notes

2026-10-21 03:20:15 GMT

Eight Bits of Trust; eMudhra's CA keys cracked in milliseconds
One of eMudhra's certificate authority private keys is the number 4.
Not a number that starts with 4, or the number 4 followed by a few hundred random digits, just, 4... Another one is 56, and another is 115. I know, because I recovered all of them from their public certificates on my laptop just now, and it took less than a second.
What happened
On Saturday 17th October a security researcher reported to Apple, Google, Microsoft, Mozilla and eMudhra that the private keys for eight eMudhra intermediate certificates were compromised. Chrome pushed a CRLSet update blocking them that evening and Mozilla blocked them in Firefox via OneCRL a few hours later. On Tuesday 20th, Mozilla announced it publicly and shipped an NSS update removing the eMudhra root, and Chrome confirmed the root is going in Chrome Root Store v43.
The eight intermediates are six TLS issuing CAs (DV, OV and EV, two generations each) and two code-signing CAs, all created in April 2025. Every one of them was also cross-signed by Sectigo's AAA Certificate Services root in May 2025.
That's the "what", but it's the "how" that's the interesting part, and it was summed up in one line on the thread by Ian Carroll:
They are inherently weak single-byte keys that anyone can factor, and the issue cannot be contained.
What a private key actually is
These are elliptic-curve keys on the P-384 curve. The private key is just a number, d. The public key, the thing that goes in the certificate for the world to see, is d × G, where G is a fixed point on the curve that everyone uses and "×" means adding G to itself d times using the curve's special arithmetic.
Going forwards is easy, but going backwards, from the public key to d, is considered to be impractical. That's the entire security model, and it only holds if d is enormous. A P-384 private key should be a random 384-bit number, which gives you 2³⁸⁴ possibilities (or roughly 10¹¹⁵), so nobody is ever going to search that.
eMudhra's keys look like this:
d = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004
A P-384 private key should look like this:
d = 0x48ac06790886c80c48d31691fd4c0fe9ce3207f9807f2fe571d6e4ec426d78644298fc53df2b92566970e757ac998c34
That's 47 bytes of zeros and then one byte, and all eight keys are like that. A single byte has 256 possible values, so the "search" is: compute 1 × G, 2 × G, 3 × G, and stop when it matches the certificate, which is at most 255 steps.
So the whole thing, every certificate those CAs could ever issue, every client that trusted them, rested on eight bits.
I checked
Mozilla attached the affected certificates to their announcement, so I pulled all 16 (8 keys, each used in two issued certificates: once by eMudhra and once by Sectigo) and brute-forced them. Every single one fell over instantly, the six TLS values, and the two code-signing keys are just as weak:
Intermediate
Type
d
EM DV TLS CA - G3B
TLS
156
EM DV TLS CA - G3C
TLS
230
EM EV TLS CA - G3B
TLS
115
EM EV TLS CA - G3C
TLS
56
EM OV TLS CA - G3B
TLS
155
EM OV TLS CA - G3C
TLS
4
EM OV CS CA - G3B
Code signing
66
EM OV CS CA - G3C
Code signing
237
It's interesting that nothing about these certificates looks wrong. A public key derived from d = 4 is a perfectly valid point on the curve, the encoding is fine, the curve is fine, every structural check passes. The only way to find out is to try.
Why "it cannot be contained"
Normally when a CA key is compromised, someone stole it! There's a thief, there's a moment it happened, and you can at least reason about who now has access to that key.
Here, nobody had to steal anything. The key was effectively public from the day the certificate existed. Anyone who looked at one of these certificates, at any point since April 2025, could have recovered the key in milliseconds on commodity hardware. That's a 17 month window and there is no way to know whether someone did.
Chrome made the point that because Chrome enforces Certificate Transparency, and no TLS certificates chaining to these CAs ever showed up in CT, no forged certificate could have been trusted by default in Chrome. That's true and it's reassuring for browsers. CT detects mis-issuance though, it doesn't prevent it, and a lot of software doesn't check CT at all.
Who's exposed today
Mainstream and updated browsers are likely absolutely fine. Chrome and Firefox block the intermediates directly and both require CT, and Safari requires CT too.
Everything else is a different story, though. Most non-browser TLS clients (so basically everything else, with default settings), things like curl, Python, Node, Go, Java, git, package managers and every script and daemon you've got, do three things that matter here: they trust a CA bundle on disk, they don't check revocation by default, and they don't check CT. So the fact that eMudhra and Sectigo have revoked these intermediates doesn't help them at all. This is something that I find often when talking about TLS and PKI, understanding just how massive the client ecosystem is can be overlooked. We often focus on this in training when we look at modern solutions for revocation like CRLite, which works wonders on the desktop browsers, but does nothing for any other TLS client. Consider what needs its root store updating now, and this is just the tip of the iceberg:
curl | sh installers and self-updaters. Many tools install or update by downloading a script or binary over HTTPS with no signature check (rustup, nvm, Homebrew's installer, countless "install.sh" pages, IoT firmware updaters). A forged certificate here means running the attacker's code, often as root.
CI/CD pipelines. GitHub/GitLab runners, Jenkins and build containers fetch dependencies and push artifacts, while holding cloud keys, registry tokens and signing keys. They run on stale base images in shared networks, and they're all curl, Python, Go and Node underneath.
Server-to-server API calls. Payment providers, webhooks, OAuth token exchanges and cloud SDKs (AWS CLI and boto use their own certifi bundle; Terraform and kubectl use Go). These carry API secrets and customer data in headers.
IoT, embedded and OT devices. Cameras, routers, cars, medical devices, smart appliances, payment terminals and industrial controllers phoning home for commands and updates. Their bundles are frozen until 2039, which is the "cannot be contained" point made real.
Windows code signing. It isn't TLS, but it's the same flaw: Windows trusts the eMudhra CS root directly. Malware signed with EM OV CS CA - G3B/G3C looks like signed software from a real publisher to anything that doesn't check revocation.
I tested this on my own machines using a local server and a certificate for api.stripe.com, a name that we can all likely agree is very high value. With default settings, curl said SSL certificate verify ok, Python completed the handshake, and Node said authorized: true. That was true on every Linux and macOS machine I tested. On Windows, CryptoAPI accepted the chain unless revocation checking was switched on, and even then only one of the two routes came back as revoked.
scott@Middle-Earth:~$ curl -v --resolve api.stripe.com:18888:127.0.0.1 https://api.stripe.com:18888/
* Added api.stripe.com:18888:127.0.0.1 to DNS cache
* Hostname api.stripe.com was found in DNS cache
* Trying 127.0.0.1:18888...
...snip...
* Server certificate:
* subject: CN=api.stripe.com
* start date: Oct 20 18:39:57 2026 GMT
* expire date: Oct 21 18:44:57 2026 GMT
* subjectAltName: host "api.stripe.com" matched cert's "api.stripe.com"
* issuer: C=NL; O=eMudhra BV; CN=EM DV TLS CA - G3B
* SSL certificate verify ok.
> GET / HTTP/1.1
> Host: api.stripe.com:18888
> User-Agent: curl/7.68.0
> Accept: */*
>
...snip...
< HTTP/1.0 200 ok
< Content-type: text/html
<
<HTML><BODY BGCOLOR="#ffffff">
<pre>
s_server -accept 127.0.0.1:18888 -cert /tmp/tmp.rBcIpjTbZV/leaf.pem -key /tmp/tmp.rBcIpjTbZV/leaf.key -cert_chain /home/scott/code/test/intermediate-sectigo.pem -www -quiet
...snip...
</pre></BODY></HTML>
...snip...
* Closing connection 0
* TLSv1.3 (OUT), TLS alert, close notify (256):
scott@Middle-Earth:~$
You can put any other hostname you want in that certificate and you have everything you need to intercept that device's traffic, all you have to do is get on the network path.
What you should do now
It's fortunate that the steps required here aren't particularly complicated for the devices you can update, and the advice essentially boils down to 'update them'. The problem is the devices you can't update or update easily.
Update everything that ships a CA bundle: your OS ca-certificates package, certifi, Node, Homebrew, and rebuild your container images once the base images pick up the change.
Devices you can't update are the hard part. Routers, printers, TVs, appliances with frozen firmware will trust these certificates until expiry, which is July 2039...
Eight bits. For 17 whole months, that's all that stood between a huge amount of non-browser software and a forged certificate for any site blowing the security on all of your encrypted traffic.
Sources
MDSP thread: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/Kp1v6CPuAAAJ
Research announcement: https://emudhra.we-have-a-problem.com/
Update 20th Oct 2026 20:16 UTC
Shortly after publishing, Mozilla made their incident ticket public: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449
eMudhra have given their account of what happened on that ticket. It seems there was a bug in the script used during the ceremony, a second, weak key pair was created on the HSM, and having similar names a human error lead to the wrong keys being used for the CSR. Nothing in the text of my article above has changed as a result of this new information. I can also confirm that a simple prompt in an AI agent allowed me to recover the private keys of the CA. Claude was able to recover the private keys with a single prompt.
https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/
https://storage.ghost.io/c/ee/88/ee889f88-37ef-43e5-9180-f9b88ee6261d/content/images/2026/10/emudhra.png
https://storage.ghost.io/c/ee/88/ee889f88-37ef-43e5-9180-f9b88ee6261d/content/images/2026/10/Logo_of_eMudhra_-2026-.svg
#rss #feeds #linksharing #qwibbit

2026-10-16 04:39:56 GMT

Passkeys Are Not a Trap
A post called Passkeys are a trap. Do not use them. has been doing the rounds over the last few days, making it pretty high on Hacker News, and I've had it sent to me many times with an 'is this true?' kind of vibe. It's written for "non-technical citizens of the web", and the headline advice is to stop using passkeys and go back to TOTP codes and passwords.
The Argument
The post makes what appears to be one central claim: Passkeys support something called attestation, which lets a website ask for cryptographic proof of what made the passkey.
The author calls this a "hidden dial" and argues that sites will slowly turn it up, until you're only allowed to log in with approved software on an approved operating system, with no modifications, no LineageOS and no sharing your Netflix password. Throw in uBlock Origin, the FIDO Alliance membership list and the UK's image-scanning proposals, and the conclusion is that passkeys are "not designed to prioritize your interests". <that-escalated-quickly.gif>
It's a compelling story. It just doesn't match how any of this actually works...
Your Passkeys Don't Attest
The passkeys most people use are synced passkeys, stored in iCloud Keychain, Google Password Manager, 1Password, Bitwarden or whatever other software of your choosing. These passkeys don't give websites an attestation statement at all, and though a site can ask, what comes back is none. I know this because I wrote an opensource passkeys library and made it available to everyone.
If a consumer website decided tomorrow that it would only accept attested passkeys, it would lock out almost all of its own users, instantly. What website is going to do that? Besides, the guidance for consumer sites has been to not even request attestation for years now.
Attestation Isn't What You Think It Is
The post describes attestation as proving "that an approved passkey manager, operating system, and firmware are in use" which is simply not true.
When it is present, WebAuthn attestation tells the site the make and model of the authenticator, identified by its AAGUID, with a certificate chain from the vendor to back it up. It says nothing about your OS, your browser, your extensions, whether your phone is rooted or jailbroken, your firmware version, or even what colour it is.
The YubiKey Recommendation
This is the part that surprised me the most. For people who want stronger security, the post recommends a hardware security key like a YubiKey, because it "avoids OS-wide attestation".
YubiKeys are the authenticators that do attestation. Every one of them ships with a Yubico-issued attestation certificate, and enterprise attestation exists specifically so organisations can require approved hardware keys. I'd still recommend a YubiKey to anyone who wants one, they're excellent and I use them, but if attestation is the thing you're worried about, the post's own recommendation pushes you towards attestation rather than away from it!
TOTP Is a Step Backwards
The post holds up TOTP as "already" a great solution. TOTP is better than a password alone, absolutely, but it has one big weakness: you can type the code into the wrong website, just ask my good friend Troy Hunt. Phishing kits like Evilginx sit in the middle, relay your password and code to the real site in real time, and walk away with your session. This isn't theoretical, it's how a huge number of account takeovers happen today and we have the evidence to prove it.
This is the problem that passkeys solve. A passkey is bound to the domain it was created for, so your browser simply won't use your example.com passkey on examp1e.com. There's no code to read out and nothing for the user to get wrong. The author even concedes this in the addendum, saying that passkeys are domain-bound and resist man-in-the-middle attacks, but still tells readers to avoid them. Swapping a phishing-resistant credential for a phishable one is a really bad trade...
What You Should Do
Keep using passkeys! Wherever a site offers one, take it, and store it in a password/passkey manager you trust. If you want to be able to move your credentials around, pick a provider that supports that. If you're worried about attestation creeping into consumer logins, then that's worth pushing back on, loudly (if it ever happens). But it hasn't happened, the biggest providers don't support it, and avoiding passkeys today while you wait for it won't protect you from anything, it just leaves you open to phishing.
Sources
I have some experience in this area:
I created WhyNoPasskeys.com to track the availability of passkeys on the Web.
I built and deployed passkeys support on my own SaaS company.
We built our own passkeys library and had it security reviewed.
I wrote about Security considerations when using Passkeys on your website.
I wrote Passkeys 101: An Introduction to Passkeys and How They Work.
I made our passkeys library opensource for everyone to use.
I've done extensive security testing of passkeys implementations.
I've openly acknowledged the limitations of not using attestation on passkeys.
I think most of all that it's important to say I use passkeys everywhere I can because they're currently the best thing we have available to protect our accounts. And they're not a trap.
https://scotthelme.co.uk/passkeys-are-not-a-trap/
https://storage.ghost.io/c/ee/88/ee889f88-37ef-43e5-9180-f9b88ee6261d/content/images/2026/10/passkeys-trap.png
https://storage.ghost.io/c/ee/88/ee889f88-37ef-43e5-9180-f9b88ee6261d/content/images/2026/10/image.png