Rendered at 13:34:49 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
jasonjayr 2 hours ago [-]
> 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...
Quick -- we need to MITM all the smart TVs so they can be jailbroken in one fell swoop!
__MatrixMan__ 1 hours ago [-]
Devices that are smart enough to talk to the internet but not smart enough to let the user install their own certs should not exist.
ezoe 1 hours ago [-]
These devices are already very weak and many of them even do non-TLS updates with no signing check anyway.
If it has been so weak already, it can't be weaker.
Sayrus 39 minutes ago [-]
Not always true. I have IoT devices where a valid certificate is useful because the original host doesn't exist anymore and the certificate isn't pinned.
Flashing the devices require direct UART/USB access which may involve soldering, if it even exists. This leak is gold for those because these devices will never get an updated CRL.
justincormack 2 hours ago [-]
Some of them seem to do some cert pinning
mschuster91 2 hours ago [-]
> > 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...
The interesting question is, how many of these devices will have the compromised CA root certificate in place?
Oh and another thing is problematic, many a Java app ships with its own keystore.jks if it needs to trust some privately hosted endpoint, and that keystore.jks may or may not contain the compromised CA root certificate... updating the OS will not catch this kind of stuff.
1 hours ago [-]
binyu 2 hours ago [-]
[dead]
childintime 10 minutes ago [-]
1. So there was no certification of the certifiers?
2. This is stupidity that rises to the level of being malicious. There is no excuse, this was a fraud. Their business was literally to promise security and.. make a profit. Nothing was ever delivered.
john_strinlai 28 minutes ago [-]
new email from wayne, who is the original reporter:
Yeah, out of the box. CCADB was intended to be a quick corpus test before looking at subscriber certificates...
I've done a far more thorough check of all existing CCADB certificates, thankfully no more hits. Most of my time has been spent going over the basics that everyone assumed someone else had already done - a critical mistake to ever make near security.
So unless someone has significantly more computational resources or access to more cryptanalysis research the low-hanging fruit has been caught so far.
This repository was archived by the owner on Aug 19, 2026. It is now read-only.
I guess now that we've checked, nobody will ever make a mistake like this again so we don't need this anymore? :)
fortran77 15 minutes ago [-]
You can still use a read-only archive.
jlmorton 4 hours ago [-]
In retrospect, having 100 trusted certificate authorities might have been excessive.
tclancy 3 hours ago [-]
In retrospect, not having a tiny competency check may have been an oversight.
2 hours ago [-]
3 hours ago [-]
m3kw9 24 minutes ago [-]
How are they trusted if they can just generate any key they like in their back room?
otabdeveloper4 3 hours ago [-]
Correct, we only need zero.
sebzim4500 2 hours ago [-]
Interesting, what would be the alternative?
I mean specifically for the use case of the browser warning the user if there is a MITM between them and e.g. their bank.
__MatrixMan__ 28 minutes ago [-]
Stop validating names, start signing content.
Scan a QR code when you open the bank account, add it to the keys you trust as authorities on financial things. When your browser runs accross data tagged "financial" it checks the trusted keys in that domain and renders it only if it was signed by a key that is trusted in that domain (the domains prevent your bank from abusing that trust by causing you to see political ads or some such).
If you ever see something that you suspect is malicious, you untrust whichever key signed it and take it up with whoever asked you to trust their key. If you verify it's malicious, gossip the bad keys to your friends so they can distrust also.
Ohentis 41 minutes ago [-]
I quite like how i2p does it. Public keys are part of addresses, human readable names are user defined and shared but static.
josephg 2 hours ago [-]
Make dns secure and put certs / public keys in dns. Control over dns already gives you the right to get tls certs. It should just be connected directly. We don’t need CAs.
three14 1 hours ago [-]
tptacek argues that DNSSEC is too flawed to actually do this:
He's right. DNSSEC is a mess, and we should fix that. We should fix that whether or not we delete CAs because CAs rely on DNS to verify that you own your domain. If DNS isn't secure, neither are CAs.
In the long run, fixing bugs is almost always better than working around them. DNSSEC is a bug. So are CAs. We can and should fix both.
ranger_danger 30 minutes ago [-]
I have seen their comments across this site for a very long time. Unfortunately I do not respect or put any stock in what they say, because of how unbelievably rude and dogmatic they are, and always have been.
"As a rule, strong feelings about issues do not emerge from deep understanding."
icedchai 19 minutes ago [-]
Fortunately, you can investigate this stuff for yourself and develop your own opinion. IMHO, DNSSEC doesn't actually "secure" much of anything. It can be disabled trivially by anyone operating a resolver. As I mentioned elsewhere, none of the major sites (FAANG) use it. What does that tell you?
shiandow 2 hours ago [-]
Making DNS secure is not trivial though. In a way that's just moving the problem.
josephg 17 minutes ago [-]
A secure DNS is valuable whether or not we get rid of CAs, since CAs rely on DNS queries to verify domain ownership.
And if we have a secure DNS, then CAs are completely redundant. I'd much rather trust a handful of domain registrars than a handful of domain registrars, plus 100 random questionably competent organisations all over the world. Especially when any one of them can generate keys for every domain on the planet.
vesinisa 2 hours ago [-]
Isn't this what DNSSEC solves?
muvlon 2 hours ago [-]
DNSSEC deployment has been anything but trivial. This APNIC post from 2024 estimated that about 1% of DNS queries were being validated via DNSSEC: https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/. That's more than 25 years after the IETF first standardized DNSSEC.
giantrobot 9 minutes ago [-]
2107: The year of IPv6, DNSSEC, and The Linux Desktop.
shiandow 58 minutes ago [-]
It should, though it achieves that goal by a chain of certificates not unlike CAs just tied to DNS. Like I said, it essentially just moves the problem.
Which might still be better, if only because it limits the surface area.
braiamp 2 hours ago [-]
That still requires trust stores to be distributed to the clients and some clients don't need that baggage on the dns. Also, dns is by default insecure, dnssec is a configuration nightmare
otabdeveloper4 2 hours ago [-]
> That still requires trust stores to be distributed to the clients
There's no such thing as a "trust store" in practice. To be "trusted" you just need to demonstrate you have control over a DNS TXT record, and we don't need a special "store" or intermediary for that.
Certificate authorities are an artifact of a bygone time and an entirely different model of internet infrastructure.
woodruffw 1 hours ago [-]
The trust store refers to the collection of parties that ultimately verify the signed claim of your control over a domain, which might have taken the form of a DNS TXT challenge (or any other number of challenges). You still need it, because there would otherwise be a basic circularity when determining whether to trust a connection.
(Moving the PKI into DNS does not remove it, it just moves it around.)
josephg 7 minutes ago [-]
> (Moving the PKI into DNS does not remove it, it just moves it around.)
Better in DNS though. You could have certs mirror the structure of DNS. Install a single root signing key for the top level DNS registry on client devices. Then you can query that to find out the signing keys for .com, .net, .au, etc. And continue from there.
One big problem with the CA system is that any CA - even the most incompetent - can sign certificates for any domain. If trust was moved to DNS, there would only be a single organisation that could forge certificates for any given domain. Using 7 as a private key? What a joke. The CAs aren't worthy of trust.
We already have to trust the domain name registrars anyway, since CAs query them to figure out if you own a domain before signing a certificate. In total, removing CAs would not only simplify the system. But it would allow scoped signatures. And we'd end up needing to trust far fewer actors to have a secure internet.
asksomeoneelse 2 hours ago [-]
But how do you make DNS secure without CAs?
growse 2 hours ago [-]
You just have one big one on the root.
(Half joking).
josephg 3 minutes ago [-]
Better to trust 1 organisation than trust 100.
asksomeoneelse 1 hours ago [-]
Is that a reference to the Root Key of DNSSEC?
lukewarm707 2 hours ago [-]
For me the complexity of anything connected to public internet is now over what I can secure.
I genuinely can't say I secured a PC, when it needs to phone home for a configuration at this point.
We are most likely over the line for needing to airgap a personal PC.
embedding-shape 2 hours ago [-]
The first time you go to the bank, you do the "trust exchange" (maybe scanning a QR? People sure love that) that verifies future connections, similar to how you acquire digital certificates today when you deal with the government online and similar.
Edit: > Every time you access your bank on different devices normalizes it so that visiting a typo domain would show the dialog and many would just click through.
Show the dialog? What dialog? There is no dialogues here, you cannot login to the bank unless you've verified the connection. You do it with your phone, then you can propagate the trust from there to other devices if needed.
bluehatbrit 2 hours ago [-]
Not all banks have physical locations, not everyone has the ability to get to the ones which do.
You can't walk back from the existing expectation and ease of use we have today. It's just not going to happen, people will opt for the current path because it's easy and seems good enough to them.
Most normal people don't even know this whole thing is going on. They don't know the difference between http and https other than "it's secure".
If we want to improve on this, it has to come with the current level of ease of use at a minimum.
__MatrixMan__ 5 minutes ago [-]
Presumably you had some reason to trust the bank in the first place. Maybe a recommendation from somebody you know? Maybe get the key from them.
The current level of ease is not being achieved securely. If it's not possible to do so, we should walk it back.
monsieurbanana 1 hours ago [-]
> If we want to improve on this, it has to come with the current level of ease of use at a minimum.
OR it has to be a situation catastrophic enough. I don't think this one is, but it's hard to be optimistic for the future
whywhywhywhy 2 hours ago [-]
Every time you access your bank on different devices normalizes it so that visiting a typo domain would show the dialog and many would just click through.
u8080 20 minutes ago [-]
Like...TOTP or FIDO2?
lirolero 2 hours ago [-]
[dead]
BirAdam 3 hours ago [-]
or, perhaps you need more so that one being stupid doesn't effect so much.
epanchin 2 hours ago [-]
Each CA is like a padlock locked in series with other padlocks. The weakest padlock is the only one that matters.
akerl_ 39 minutes ago [-]
In a world with CT logs and CAA records, is that actually the case?
zbentley 14 minutes ago [-]
Yes, because as we are seeing with this incident, plenty of things don’t check CT logs (and thus can still be hacked if CT isn’t published for bad certs), and CAA records are fundamentally advisory.
caaqil 2 hours ago [-]
> perhaps you need more so that one being stupid doesn't effect so much.
So you create more surface area for vulnerability? We might already be at or close to the sweet spot. Security is hard.
Gabrys1 1 hours ago [-]
I would assume that the client would need to validate the certs against more than 1 trust path (for the comment to make sense)
It's been a while since this one popped up.
It's surprising how many of those doodles are surviving the test if times, in the midst unexpected ways
walrus01 3 hours ago [-]
Hey, that's the same combination I have on my luggage!
wowczarek 1 hours ago [-]
Good job the Earth doesn't have an air shield protected by this byte or we'd be Skroob'd.
supernes 3 hours ago [-]
Two more things to note about impact assessment: Flatpak uses the selected runtime's baked-in trust store (I think), so any apps may be susceptible even if you update the system package. Containers also don't inherit the host's trust store and use the one from the base image.
nmeofthestate 2 hours ago [-]
I wonder how someone stumbled upon this - maybe leaked by someone inside eMudhra?
Since there's nothing to indicate that the private key was all zeroes and one non-zero lsbyte, and presumably nobody would try to brute-force a private key.
cvwright 1 hours ago [-]
I suspect that they read the article last Friday about Claude finding the origin of the ECDSA constants. That was only a few hours before Google received the vulnerability report.
The two cases are very similar. The only difference is that the weak randomness was harmless in the earlier story, and here it’s devastating.
Of the thousands of people bored with a swarm of AI agents, is it not plausible that somebody would just say "hey, let's do a vibe check to see whether any CAs are trivially crackable"?
consp 2 hours ago [-]
> and presumably nobody would try to brute-force a private key.
Why not? There are examples of RNGs providing very poor entropy which might be a reason to check it (looking at you Sony).
nmeofthestate 2 hours ago [-]
Just seems weird for anyone to focus on trying to crack private keys starting with absurd 8-bit values that "nobody would use for a private key", let alone bother to do it at all, given the search space.
smaudet 16 minutes ago [-]
And here you learn why security is often just theater (not saying a proper elliptic key is theater)...
It took less than a second to factor this key. Why not attempt, say, to factor every CA, with a budget of less than a minute each?
The reward/risk ratio is skewed so heavily in favor of trying, the only reason not to is this idea that it is "impossible".
It's clearly not, hence, the theater. Your locks don't have to work, they often only have to look like they work...
consp 2 hours ago [-]
I would not expect anyone to be on the lookout continuously, but like the researcher doing a "yolo" and trying. There are enough people out there that it is likely to happen at least once in a while. Or for instance someone looking for a firmware exploit in a downstream device.
1 hours ago [-]
tclancy 3 hours ago [-]
I will say, there’s something almost reassuring when something goes boom that badly and the story is really silly. It’s like [horrific human-caused disaster] but it’s because of a Three Stooges episode.
skinfaxi 38 minutes ago [-]
The more cynical among us think that is part of it. Remember when Bush Jr. became a bumbling idiot for a few years?
As someone from Gothenburg, Sweden (often referred to as gbg) I shall answer:
A private key is a tiny number you don't need to share publicly because it is easy enough to guess.
Hamuko 3 hours ago [-]
Maybe they were counting on the fact that usually the right answer to “I’m thinking of a number between 1 and 10” is “7”.
bombcar 2 hours ago [-]
Isn't 4 simply 2 bits?
Silly 2-bit outfit.
Maybe it's 3 bits.
patrickthebold 2 hours ago [-]
I think the way that the bits are counted is based on the pool from which the number was randomly drawn. So it's possible they had 256 bits of entropy but got really unlucky.
4 hours ago [-]
Qision 4 hours ago [-]
It feels like they chose the private keys by hand.
PalmPilotProMax 4 hours ago [-]
Artisanal cryptography. Hand-picked private keys salted with organically sourced nonces.
tclancy 3 hours ago [-]
Brooklyn-based. Guy in overalls and a waxed mustache hands out the bits.
donandon 3 hours ago [-]
Made with love
account42 3 hours ago [-]
Sharing is caring after all.
muvlon 3 hours ago [-]
My bet is on one of
- A sequence number being accidentally used as the private key or
- The private key being generated securely but then accidentally truncated to 8 bits (e.g. writing a single char into a zeroed buffer when you should've memcpy'd from a char*).
The sequence number idea is supported by the fact that two of the G3B private keys are consecutive numbers. I ran a quick Monte Carlo simulation and if I got it right, sampling 8 keys from [0,255] uniformly at random (as in the truncation scenario), you'd expect them to contain 2 consecutive numbers only about 18% of the time.
account42 3 hours ago [-]
All the numbers also have digits going from left to right on a keyboard. I think the manual "random" input theory is plausible.
33 minutes ago [-]
muvlon 2 hours ago [-]
Oh wow, that is even more damning. Only 146 out of the possible 256 keys have this property. You only have about a 1% chance to get that 8 times in a row (A little more than 1% if sampling with replacement and a little less if sampling without. You'd expect them to at least not use the exact same key twice but at this point???).
The fact that there are more than the "4" one, and all the low numbers are below 384 (384 being the bits for private key) makes me think whoever was creating these thought "Oh a random number between 1-384" let me choose... 4! (156, 230, 115, 56, 66, 237, 155)...
A long time ago one time pads used to be chosen by hand by women picking numbered lottery balls out of a spherical tumbling machine on a table.
TazeTSchnitzel 3 hours ago [-]
Could HN start feeding submissions through Pangram so us human readers don't have to suffer with reading the nauseating AI-prose?
swiftcoder 3 hours ago [-]
Count yourself lucky - compared to Claude's prose, this is fairly readable.
jadamson 3 hours ago [-]
It reads fine to me. If it is AI, I'd like to know which one so I can use it too.
stratos123 3 hours ago [-]
It reads okay to me too, yet Pangram says it's mixed - the "What a private key actually is" section is AI, so is 'Why "it cannot be contained"' and some others.
TazeTSchnitzel 3 hours ago [-]
I think it's a hybrid text. The section about how elliptic curve keys work is particularly aggravating. Unfortunately it's also the only section that gave me new information.
karel-3d 2 hours ago [-]
It has parts that are human written and parts that are generated. I couldn't tell at first, but now seeing it in Pangram, it's kind of clear.
marsven_422 3 hours ago [-]
[dead]
Gabrys1 48 minutes ago [-]
This has a big upside: I can now MITM any Android app / IOT device without any suspicious set up on the device? (given it'll run on the unupdated OS and that cert revocation is not ON).
eob 35 minutes ago [-]
With the speed of vibe coding.. I'd expect the "Reverse Engineer Anything" folks to come out with a "Man in the Middle Anything" app by lunch
kyleomalley 50 minutes ago [-]
Question: what about the other trusted roots? Has anyone tested them?
I’ve tested most of them (from historical archives) and have automated testing any new CA certificates that show up in CT.
I’m calling the check “luggage code entropy” (1 byte).
It was a mistake to trust so many root CAs and misapply the same level of trust where clearly it is impossible to independently verify and most of the accountability is smoke and mirrors. We need to be asking “why” here, the stated reason needs to be much more than “because webtrust audit” and “we recorded the entire operational process for key material handling on YouTube with this open source implementation of key ceremony tooling and have underwritten the strength of the private key with a few $mm dollars, to be paid out to the rest of the roots for the shared reputational damage to the entire ecosystem should we fuck up (intentional or otherwise).
bandrami 36 minutes ago [-]
Shakti de. This should be firm-ending for them but I fear it won't be.
eviks 2 hours ago [-]
> recovered all of them from their public certificates on my laptop just now, and it took less than a second.
Why wasn't this second spend by the parties accepting those certificates as valid before they were accepted?
Kind of hard to understand how a bug would have generated a second pair of key so bad, and how would human would have ended up using them. Never attribute to malice what can be attributed to stupidity, but sometimes you wonder.
amoss 50 minutes ago [-]
Given the usefulness of this to anybody who knew about it between the ceremony and now - assume malice.
sobkas 3 hours ago [-]
Any sufficiently advanced malice is indistinguishable from stupidity.
RetroTechie 39 minutes ago [-]
The reverse is also true:
Any sufficiently advanced stupidity is indistinguishable from malice.
SAI_Peregrinus 42 minutes ago [-]
Never assume stupidity for what can adequately be explained by profitable malice.
Never assume unprofitable malice for what can adequately be explained by stupidity.
dist-epoch 3 hours ago [-]
And an equal amount of stupidity in the whole ecosystem, apparently there are no "unit-tests" for trivial failure modes, like 8 bits of entropy, before adding a CA to the trusted list.
What next, googling the public key finds a 2 year old pastebin with the private key?
silvestrov 3 hours ago [-]
Even just a human glancing at the private key should do it.
Don't they even test script changes on a staging server? How could there be such a script error in production that was not caught in testing/staging?
This sounds very like a fundamental organization error, not an innocent whoopsie. It should lead to a permanent ban of the organization.
karel-3d 2 hours ago [-]
Well humans should NOT glance at private keys! That is the whole point of HSMs!
silvestrov 32 minutes ago [-]
But eMudhra wanted to (was required to) export the keys.
So using an HSM in the first place is a security theater. Or that this HSM isn't really an HSM since it allows for export of the private key.
The trusted enclave in a MacBook is more secure than this HSM.
xvector 5 minutes ago [-]
Most HSMs used by CAs are pretty trash tbh.
consp 2 hours ago [-]
I'm still flabergasted the HSM allowed this key to be generated. Then again, I've worked with HSMs, there are always many mistakes in the firmware, usually less severe though.
karel-3d 2 hours ago [-]
It seems there was some issue with the ceremony with some wrapping/unwrapping scripts.
They explicitly said they wanted to export the keys from the HSM; the keys were intended for USA/Europe (for sovereignty reasons) but were never actually used.
It seems the HSM itself worked, their ceremony around wrapping/unwrapping didn't.
consp 1 hours ago [-]
Makes more sense.
I'm sure the Utimaco's used (haven't worked with one) also allow all slots to contain the same name or keys with the same name and the device always selecting the first one if you only provide the name and not the slot ID or token identifier. Don't ask how I found out the hard way.
karel-3d 45 minutes ago [-]
Yes there was something about key names in the write-up (which I cannot find now)
I made test.key4.lol if you want to quickly check if your device/browser is vulnerable still.
dbcooper 3 hours ago [-]
All the numbers were under 384. Surely they couldn't have ...
MrDOS 3 hours ago [-]
All the numbers were under 256. Surely they did.
m3kw9 26 minutes ago [-]
This has to be a backdoor planted by hackers, mess with the key gen, say is all good. Must be known since issuance.
hypfer 3 hours ago [-]
This is not a good write-up. Yesterday's discussion did contain better data, less self-Promotion and actually asked why it happened, instead of just saying "number small".
sscaryterry 3 hours ago [-]
I wouldn't be surprised if we learn in the near future, that this was deliberate.
edent 3 hours ago [-]
I'm not so sure. If you wanted to be deliberate, you'd choose a plausible value that you could control.
No one is going to suspect `98761316832165974216498789746` is anything other than random. But `000000000000000123` looks suspicious.
K0balt 1 hours ago [-]
But that would be obviously intentional. Much more plausible deniability with 0x4.
sscaryterry 3 hours ago [-]
Why are many of them, suspicious?
kenniskrag 2 hours ago [-]
The probability of getting a 0 is the same for every digit. However, in my opinion, the probability of getting a number that starts with two zeros is 1/10 * 1/10, and the probability of getting a number that starts with the same two digits is 10 * 1/10 * 1/10.
But the probability to receive one number or the other are the same.
matsemann 2 hours ago [-]
By random chance you probably wouldn't get that many zeros. Of course, one could say it's just as random as any other string, but..
sscaryterry 2 hours ago [-]
Not a mathematician, but I'm sure the probability of them all being below 384 is going to be in the order of 0.000000001% if not less :)
kenniskrag 2 hours ago [-]
10 times the amount of digits is the possible number space.
smaller than 384 means 384 numbers (including 0) divided by the amount of possible numbers (see above) imho
SAI_Peregrinus 40 minutes ago [-]
It's a 384-bit curve, so between 0 and 2^384 which has about 115 decimal digits.
hannob 3 hours ago [-]
Makes no sense.
If it was deliberate, one would use keys that only the person abusing it has. Not keys everyone can guess if they get a hint.
bombcar 2 hours ago [-]
Deliberate deniability - if you leak a real key, it's pretty obvious you leaked a real key.
Here, you didn't leak anything, you just fucked up.
yoavm 3 hours ago [-]
Why would it be?
sscaryterry 3 hours ago [-]
Do I honestly need to enumerate what you can do if you have the keys for a CA?
swiftcoder 3 hours ago [-]
Yeah, but if you are the one issuing the CA's private key, you already, by definition, have the keys to that CA. You don't need to make stupid keys in that scenario
sscaryterry 2 hours ago [-]
In case it wasn't obvious. The NSA and many other organisation would find this extremely useful.
yoavm 2 hours ago [-]
But it doesn't make sense. Sure they'd find it extremely useful to have the key, but it doesn't need to be a weak key for it to be useful. If anything, it makes it less useful to them.
If I'm going to ask you or force you to share your password with me, there's no reason I'd ask you to set the password to 4. We might as well agree that the password would be D#!(s9fj0jalk!4af095SF42 , and it's much more likely our collaboration will continue working for years.
"Never attribute to malice that which is adequately explained by stupidity"
skinfaxi 36 minutes ago [-]
A weak key means use is unattributable.
skywhopper 3 hours ago [-]
Sounds more like extremely sloppy procedures. Which depressingly I doubt are unusual among CAs.
sscaryterry 2 hours ago [-]
As far as I know, to become a CA, with the requirements and ceremonies involved, this type of mistake must never happen. Assuming malice instead of ignorance is reasonable here. The entire premise of a CA, is trust.
woodruffw 1 hours ago [-]
There are a lot of CAs that are essentially grandfathered into root programs (and there’s no “one” root program, every OS and verifier gets to choose their own inclusion policies). They might need to jump through hoops to stay in any given program, but being there in the first place is not a strong indicator of quality.
sylware 2 hours ago [-]
The CA concept itself is flawed, unless normal users were able to cherry pick the CA they do trust, dream. And even with that, they must keep in mind that many authorities and/or mafias have very probably rogue certificates for browser invisible man-in-the-middle.
gquere 1 hours ago [-]
Doesn't ACME+CT solve this threat?
dist-epoch 3 hours ago [-]
> and no TLS certificates chaining to these CAs ever showed up in CT
Why are browsers trusting CAs which issued zero certificates since their creation 1 year ago?
3 hours ago [-]
skywhopper 3 hours ago [-]
These are intermediate roots, signed by trusted root certs, so the trust from your OS or browser is implicit to the roots it trusts.
akino_germany 2 hours ago [-]
Yes, but there was no TLS cert issued that had these intermediate certs in its chain of trust at all anywhere. So why are they a CA if they don't issue any certs?
What the chances there’s another CA key out there with something like unix time as the key?
ls65536 1 hours ago [-]
Another place to search for private key candidates would be the outputs of various common PRNGs when they have been seeded with a timestamp (for all timestamps in, say, the past 20 years).
These would look like nice random values (unlike the ones that were recently compromised), but they would be trivial to generate by anyone who knows the initial inputs (PRNG algorithm, seed, maybe starting byte position, etc.).
> 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...
Quick -- we need to MITM all the smart TVs so they can be jailbroken in one fell swoop!
If it has been so weak already, it can't be weaker.
Flashing the devices require direct UART/USB access which may involve soldering, if it even exists. This leak is gold for those because these devices will never get an updated CRL.
The interesting question is, how many of these devices will have the compromised CA root certificate in place?
Oh and another thing is problematic, many a Java app ships with its own keystore.jks if it needs to trust some privately hosted endpoint, and that keystore.jks may or may not contain the compromised CA root certificate... updating the OS will not catch this kind of stuff.
2. This is stupidity that rises to the level of being malicious. There is no excuse, this was a fraud. Their business was literally to promise security and.. make a profit. Nothing was ever delivered.
"I've had more than a few emails asking on how this was discovered. The simple answer is: https://github.com/google/paranoid_crypto
Yeah, out of the box. CCADB was intended to be a quick corpus test before looking at subscriber certificates...
I've done a far more thorough check of all existing CCADB certificates, thankfully no more hits. Most of my time has been spent going over the basics that everyone assumed someone else had already done - a critical mistake to ever make near security.
So unless someone has significantly more computational resources or access to more cryptanalysis research the low-hanging fruit has been caught so far.
"https://groups.google.com/a/mozilla.org/g/dev-security-polic...
This repository was archived by the owner on Aug 19, 2026. It is now read-only.
I guess now that we've checked, nobody will ever make a mistake like this again so we don't need this anymore? :)
I mean specifically for the use case of the browser warning the user if there is a MITM between them and e.g. their bank.
Scan a QR code when you open the bank account, add it to the keys you trust as authorities on financial things. When your browser runs accross data tagged "financial" it checks the trusted keys in that domain and renders it only if it was signed by a key that is trusted in that domain (the domains prevent your bank from abusing that trust by causing you to see political ads or some such).
If you ever see something that you suspect is malicious, you untrust whichever key signed it and take it up with whoever asked you to trust their key. If you verify it's malicious, gossip the bad keys to your friends so they can distrust also.
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
In the long run, fixing bugs is almost always better than working around them. DNSSEC is a bug. So are CAs. We can and should fix both.
"As a rule, strong feelings about issues do not emerge from deep understanding."
And if we have a secure DNS, then CAs are completely redundant. I'd much rather trust a handful of domain registrars than a handful of domain registrars, plus 100 random questionably competent organisations all over the world. Especially when any one of them can generate keys for every domain on the planet.
Which might still be better, if only because it limits the surface area.
There's no such thing as a "trust store" in practice. To be "trusted" you just need to demonstrate you have control over a DNS TXT record, and we don't need a special "store" or intermediary for that.
Certificate authorities are an artifact of a bygone time and an entirely different model of internet infrastructure.
(Moving the PKI into DNS does not remove it, it just moves it around.)
Better in DNS though. You could have certs mirror the structure of DNS. Install a single root signing key for the top level DNS registry on client devices. Then you can query that to find out the signing keys for .com, .net, .au, etc. And continue from there.
One big problem with the CA system is that any CA - even the most incompetent - can sign certificates for any domain. If trust was moved to DNS, there would only be a single organisation that could forge certificates for any given domain. Using 7 as a private key? What a joke. The CAs aren't worthy of trust.
We already have to trust the domain name registrars anyway, since CAs query them to figure out if you own a domain before signing a certificate. In total, removing CAs would not only simplify the system. But it would allow scoped signatures. And we'd end up needing to trust far fewer actors to have a secure internet.
(Half joking).
I genuinely can't say I secured a PC, when it needs to phone home for a configuration at this point.
We are most likely over the line for needing to airgap a personal PC.
Edit: > Every time you access your bank on different devices normalizes it so that visiting a typo domain would show the dialog and many would just click through.
Show the dialog? What dialog? There is no dialogues here, you cannot login to the bank unless you've verified the connection. You do it with your phone, then you can propagate the trust from there to other devices if needed.
You can't walk back from the existing expectation and ease of use we have today. It's just not going to happen, people will opt for the current path because it's easy and seems good enough to them.
Most normal people don't even know this whole thing is going on. They don't know the difference between http and https other than "it's secure".
If we want to improve on this, it has to come with the current level of ease of use at a minimum.
The current level of ease is not being achieved securely. If it's not possible to do so, we should walk it back.
OR it has to be a situation catastrophic enough. I don't think this one is, but it's hard to be optimistic for the future
So you create more surface area for vulnerability? We might already be at or close to the sweet spot. Security is hard.
“eMudhra intermediate CA compromise” | 947 points | 19 hours ago | 408 comments
There are two hard problems in computer science: naming things, cache invalidation, and off-by-one errors.
Since there's nothing to indicate that the private key was all zeroes and one non-zero lsbyte, and presumably nobody would try to brute-force a private key.
The two cases are very similar. The only difference is that the weak randomness was harmless in the earlier story, and here it’s devastating.
Why not? There are examples of RNGs providing very poor entropy which might be a reason to check it (looking at you Sony).
It took less than a second to factor this key. Why not attempt, say, to factor every CA, with a budget of less than a minute each?
The reward/risk ratio is skewed so heavily in favor of trying, the only reason not to is this idea that it is "impossible".
It's clearly not, hence, the theater. Your locks don't have to work, they often only have to look like they work...
https://xkcd.com/221
8 bits is crazytalk!
hey chatgbg what is a “private key”
A private key is a tiny number you don't need to share publicly because it is easy enough to guess.
Silly 2-bit outfit.
Maybe it's 3 bits.
- A sequence number being accidentally used as the private key or
- The private key being generated securely but then accidentally truncated to 8 bits (e.g. writing a single char into a zeroed buffer when you should've memcpy'd from a char*).
The sequence number idea is supported by the fact that two of the G3B private keys are consecutive numbers. I ran a quick Monte Carlo simulation and if I got it right, sampling 8 keys from [0,255] uniformly at random (as in the truncation scenario), you'd expect them to contain 2 consecutive numbers only about 18% of the time.
https://xkcd.com/221/
I’ve tested most of them (from historical archives) and have automated testing any new CA certificates that show up in CT.
I’m calling the check “luggage code entropy” (1 byte).
It was a mistake to trust so many root CAs and misapply the same level of trust where clearly it is impossible to independently verify and most of the accountability is smoke and mirrors. We need to be asking “why” here, the stated reason needs to be much more than “because webtrust audit” and “we recorded the entire operational process for key material handling on YouTube with this open source implementation of key ceremony tooling and have underwritten the strength of the private key with a few $mm dollars, to be paid out to the rest of the roots for the shared reputational damage to the entire ecosystem should we fuck up (intentional or otherwise).
Why wasn't this second spend by the parties accepting those certificates as valid before they were accepted?
Kind of hard to understand how a bug would have generated a second pair of key so bad, and how would human would have ended up using them. Never attribute to malice what can be attributed to stupidity, but sometimes you wonder.
Any sufficiently advanced stupidity is indistinguishable from malice.
Never assume unprofitable malice for what can adequately be explained by stupidity.
What next, googling the public key finds a 2 year old pastebin with the private key?
Don't they even test script changes on a staging server? How could there be such a script error in production that was not caught in testing/staging?
This sounds very like a fundamental organization error, not an innocent whoopsie. It should lead to a permanent ban of the organization.
So using an HSM in the first place is a security theater. Or that this HSM isn't really an HSM since it allows for export of the private key.
The trusted enclave in a MacBook is more secure than this HSM.
They explicitly said they wanted to export the keys from the HSM; the keys were intended for USA/Europe (for sovereignty reasons) but were never actually used.
It seems the HSM itself worked, their ceremony around wrapping/unwrapping didn't.
I'm sure the Utimaco's used (haven't worked with one) also allow all slots to contain the same name or keys with the same name and the device always selecting the first one if you only provide the name and not the slot ID or token identifier. Don't ask how I found out the hard way.
oh here
https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c11
No one is going to suspect `98761316832165974216498789746` is anything other than random. But `000000000000000123` looks suspicious.
But the probability to receive one number or the other are the same.
smaller than 384 means 384 numbers (including 0) divided by the amount of possible numbers (see above) imho
If it was deliberate, one would use keys that only the person abusing it has. Not keys everyone can guess if they get a hint.
Here, you didn't leak anything, you just fucked up.
If I'm going to ask you or force you to share your password with me, there's no reason I'd ask you to set the password to 4. We might as well agree that the password would be D#!(s9fj0jalk!4af095SF42 , and it's much more likely our collaboration will continue working for years.
"Never attribute to malice that which is adequately explained by stupidity"
Why are browsers trusting CAs which issued zero certificates since their creation 1 year ago?
These would look like nice random values (unlike the ones that were recently compromised), but they would be trivial to generate by anyone who knows the initial inputs (PRNG algorithm, seed, maybe starting byte position, etc.).