"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...
I have not yet been accused of arson, but it's only a matter of time.
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? :)
The one thing I don't like about archive is the inability to add new issues. If I encounter a new issue, I don't necessarily want to fork it and track the new issue myself. I don't want to take responsibility for the code, I just want to let people know so someone else can fix it if they care.
Last commit was 2 years ago anyway.
https://github.com/google/paranoid_crypto/blob/main/paranoid...
Anybody writing a system for a bank or the govt needs to have every line of code checked that it’s not doing something stupid with its crypto keys. That level of assurance would have caught this. But the process was defined too weakly.
FIPS-compliant key generator allowed key to be 4 ?
No, they just didn't check thoroughly enough
If you're talking about root certs then it's almost 350 currently trusted by at least one major operator.
If you include intermediates, you're talking more than 3,600!
They instead place the burden on individual webmasters again to actually verify that nobody has been falsely issuing for their domains. There are also some new vulnerabilities about CT logs who might be malicious.
Do you have any info on the malicious CT logs? I'd be interested to read something on that!
Good: trustworthy Often bad: trusted
Mozilla et al. could claim trust for Microsoft and then MS would be an intermediary for Mozilla. There is a long history of sketchy intermediaries like GoDaddy and others that root certificate providers like Mozilla would block at times due to abuse.
This leads to users, usually ones that are not that technically savvy, seeing 'insecure' warnings on a page that actually offers HTTPS. ..but since the root servers no longer accept them as trusted, everything that GoDaddy supported, and every intermediary (child) cert which they approved would no longer be trusted and you would see a non-secure warning.
they violated that trust.
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.
Then at the very least one of the CAs leaking isn't automatic compromise, as leaking the key still doesn't make you insecure, that would also require intercepting and changing DNS records
This really reduces how much we need to trust the CAs, because we can detect any untrustworthy actions after the fact. Now detecting after it happened is too late. But it does mean that mistakes or malicious actions are much more expensive to a CA. In practice this has really reduced the risk, especially to those whom aren't interesting enough to burn a valuable capacity on. Which is the vast majority of people. Though perhaps if you count TLS traffic weighted by importance that count is different.
When a certificate is logged to CT, you get back an SCT, and the issuing CA will normally include that in the certificate. The browser will then accept this certificate as it has the correct SCTs (there are always at least two).
The attacker issued certificate hasn't been logged, so can't have an SCT, so won't be accepted by the browser.
We can't say that no certificates have been issued by an attacker. We can say that no certificates have been issued by an attacker that a modern browser client would accept.
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.
He is not arguing that DNS security cannot or should not be improved; in fact, he explicitly states the exact opposite.
It's going to settle into general usability at just about the time cryptographers deprecate ECC entirely!
"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.
A confidential DNS has real value. Without it, ISPs actively monitor customers and sell analytics about usage upstream; there are other problems, but virtually every US user faces that one. It's hard to imagine wanting to trade confidentiality off.
A high-integrity DNS is a more dubious proposition. You'd obviously rather have integrity than not, ceteris paribus, but we have effective mitigating controls for DNS forgery, so you might imagine trading it off.
Availability also sounds like a no-brainer, until you remember that almost every other component of the networking stack also has availability issues. You might not want to trade anything at all to get a more highly-available DNS, if you're going to be just as susceptible to DOS attacks because the current DDoS meta is application-layer anyways.
There are a bunch of different approaches to securing the DNS, and they make different tradeoffs.
DoH focuses on confidentiality, and has bank-shot benefits to integrity (because it breaks forgery attacks from on-path attackers). Confidentiality is its primary purpose and it trades basically everything else off.
DNSSEC makes the opposite tradeoffs: it's exclusively for integrity, provides no confidentiality, and highly prioritizes availability (that's why it has elaborate authenticated denial systems).
Depending on what you want to achieve, "secure" DNS can make sense and actually get deployed and used, as DoH is, or it can make almost no sense and see almost no uptake.
Which might still be better, if only because it limits the surface area.
shudders
(1) We're also rearchitect the way all DNS is done so that every lookup from every phone and laptop is fully recursive, so that everyone validates DNSSEC chains instead of relying on the AD bit that cable company DPI devices switch off.
(2) People will lose all attachment to their current domain names and simply migrate to TLDs that have policies they agree with, rather than .COM and .IO, which are under the demonstrated de facto control of the NATO IC.
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.
Is this not what CAA records were intended to solve? It seems like in practice they're only used by CAs to decide if they can sign a cert for a given domain, but it seems like a client could use it to determine if a server cert was from the correct CA.
1. A domain would have to keep the CAA records for a CA in place to keep using the certificates from that CA, but that means continuing to authorise new issuance too. Right now, I can remove the `letsencrypt.org` value to stop them from issuing new certificates for me, but I can keep using any certificates I have until they expire.
2. The client would need to have support for this new DNS RR type.
3. The client would need a secure way to query DNS, which is not widespread.
I infer from the wording around there and elsewhere in the RFC that this is mostly because someone could switch issuers but still serve valid certs from the prior issuer, and there's no way an RP would have a historical record of which CAA values were in effect when to be able to determine if the issuance was valid or not.
I think the idea that CAs are uniquely incompetent is probably incorrect.
(Half joking).
The dependency of "accetpable", i.e., not self-signed, TLS certificates on DNS, i.e., a domain name in a TLD created by "ICANN", is funny when one considers that the traffic to authoritative nameservers is still unencrypted. It stands to reason that DoH and other "accepted" forms of "DNS security" are only to stop ISPs from stealing Silicon Valley's surveillance advertising racket. Neither is "DNSSEC" providing the user with any real "security"; it's protecting a monopoly. The "security" is against anyone who might try to use domains names not blessed by "ICANN"
Indeed there's no need for CAs just as there is no need for ICANN
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.
If confidentiality is required, well you already have a public key that you're using to verify content, then the content can say: "reach us at 196.7.3.45" and then you encrypt communications to that address with the same public key you use for validating content.
Or maybe they'll specify, in the content, that you should use a different key for that, but either way the chain of trust is preserved.
This would of course all be protocol level stuff, handled by the browser, not a human. They just have to maintain a list of keys they trust.
Um, I don't think you understand this problem near as good as you think you do?
>A man in the middle can pass the content along or they can refuse to do so but they can't forge a signature.
So where do you get this signature exactly so they don't MITM you the first time?
> well you already have a public key that you're using to verify content,
Who what where when why? Where did I get this public key? Who provided it? Is this my public key or their public key? How do I trust it?
>They just have to maintain a list of keys they trust.
So you've solved exactly nothing.
That's always going to depend on why you're trusting them in the first place. If somebody handed you a business card the key should be on the card. If it was a recommendation from a friend you should use whatever key they use.
If you're expecting to just type random IP addresses into your browser until you hit something and then be told that you should trust what you see... Well that's not in the cards because you shouldn't trust what you see in that scenario.
We already don't type in URL's, we send links to each other. It really wouldn't be so difficult to change the UX so that when we delegate trust in that way it's public keys that are being trafficked instead.
> So you've solved exactly nothing.
Removing untrustworthy third parties and the need to revoke trust in them on the user's behalf is the solution. Users don't know what a CA is or how they should evaluate its trustworthiness. We need a system where they're instead evaluating the trustworthiness of things they understand, like other people.
When they get burned they should have the ability to immediately revoke trust in whoever burned them. This thing we're doing where we expect them to wait around while some nerd pushes the updated list to them and to blindly trust that that nerd isn't curating that list with ulterior motives is totally bonkers.
RFC 7469 appears to be more geared towards service providers attempting to protect their users. Laudable, but we're still assuming we know something about who the user deems trustworthy, which I think is presumptuous.
It's one thing to suss out cases where somebody is lying about their name, that's pretty cut and dry. But ever since web2.0 there's no longer much of an association between the hostname and the trustworthiness of the content. If we instead provided a means of validating the content's provenance it wouldn't much matter which host was involved in its delivery.
The only 'real' problem though with this approach is it requires a trusted path for the bank to get the "JP Morgan Chase root CA cert" into my hands (like a QR code they hand me physically). Serving it up over http: or over an unvalidated SSL context at first use seems to defeat the purpose since I could be being MitMd the first time I hit chase.com. In practice most people would be angry that they couldn't use the bank's website if their new phone or PC didn't have the certificate yet, and if places start advertising their cert QRs everywhere, it will normalize the idea that you add a CA certs all the time, leading to CA cert QRs being on billboards and bus stops and eventually fraudulent ones would be snuck in that way.
We should push this into the application layer, so rather than scoping the keys to domain names let's scope them to something relevant to whatever the user authentically trusts. Something to do with their intentions for using this app. Because most users don't even know what a CA is, but they understand that most of the time they'll need to trust somebody. So let the app decide what that's going to mean because those dynamics are always going to depend on the situation.
So the user (or OS) would pass an object at runtime to indicate which keys they want the process to trust for this session. Typically it'll be another human or a company, not a server name, but I suppose it could also be a device. Something that can guard a key pair and be identified by its ability to produce valid signatures. That way you're just not relying on globally unique human friendly names at all. Doing so puts you in a cursed corner of zooko's triangle.
Users can assign a pet name for whoever they're trusting at the time they're configuring that trust since that's the moment they're best able to scrutinize the trustworthiness of this individual or company or device. Not later on when they're installing software updates and have no context for the decisions they're making.
This way your application can work over alternative transport layers: carrier pigeons, lobbing an SD card over the border wall, whatever, and doesn't break just because the other party has a different name on the new transport. Relevant for when the internet goes down and you still want it to work with other hosts on the LAN or the local mesh or whatever.
'Cos no scammer would ever be so sneaky as to leave off the tag... /s
> it up with whoever asked you to trust their key
'Cos no scammer would ever pretend to be that person... /s
As for tagging... We could use something like color to indicate domain. So if your well trusted plumber is giving financial advice maybe it shows up, but not in the "financial" color? Idk it seems like a solvable UX problem.
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.
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
The current level of ease is not being achieved securely. If it's not possible to do so, we should walk it back.
This works great for something that are obvious. "Hey, this plumber was good and cheap".
The problem is this completely and totally breaks down where things are obscure. When things turn from "reals" to "feels" the amount of manipulation a bad actor can perform is great.
I'm trying to do more than that. If we validate claims made by the content as anchored in the user's trust graph, we don't have to care which server it came from--it's trusted for different reasons. Are you saying we shouldn't try just because it's hard?
Trust doesn't scale, and the internet is something that operates at scale.
All of the systems you're talking about have already existed and been tossed by the wayside. People could always have exchanged things like GPG keys, and yet here we are in a world in which we don't.
The vast majority of your users do not want to manage trust. They want it to be taken care of. Almost no one gives two shits about a trust graph, except maybe nerds like you or me. Exposing the average person to these concepts doesn't increase trust. It just makes the world more confusing for them.
This starts to delve into the monkeysphere and how many 'close' relationships people can form. If we have just a few things we trust it might work. Once you get over 15 or so it starts breaking down, and at 100 it's out of the question. Again, trust works on our evolutionary monkey brain that is used to a small tribe and systems requiring personal trust do not scale past that.
Trust graphs are worthless when they are built on a house of security lies. It's easy to get kicked out of them, but nearly impossible to secure your systems to the point you can keep attackers from stealing them and pretending to be you.
We need to recognise that is impossible. Making getting into a bank account easier for the owner does so for everyone else too. And also makes it easier for the bank to ditch the secure fallback - a building.
And ask why vendor-indepedent trust shops aren't sprouting in every locale. Answer: same security problems.
We are well and truly doomed to living in a scammers' paradise.
And also, how is my bank supposed to safely generate and distribute a key that we can exchange securely if an organisations who's primary purpose to generate these keys couldn't even manage to do so.
I have plenty of other services I use too. Suddenly my phone company, doctors, supermarket has to create and distribute keys for me to go around collecting so that I can securely talk to them and we have to do this in a way that stops anyone from swapping those keys out before they get to me.
I mean the current system isn't perfect, but it's a Utopia compared to that.
It does seem to lean on the physical bank-front being trustworthy (no evil clerks).
If we’re meeting physically to set up connections, we could even use something like a one-time-pad, and be information-theoretically secure. How many bits does your bank really need to send you securely anyway?
Like it seems your disagreement is that you're pointing out there are systems today that trust WebPKI CAs but don't validate CT/SCTs. I'd agree that that's an issue and I want those systems to join the world where CT exists.
As I said, in a world with CAA records and CT logs, this isn't an issue. If your CA wants to be in root trust stores, you have to put your certs in CT logs. CAA records are "advisory" in the sense that we mandate that root-trusted CAs obey CAA records and that they write cert issuance to CT logs, so a trusted CA that violates CAA records has to tell on itself in a very detectable way.
Refs: Part 1: https://scotthelme.co.uk/impending-doom-root-ca-expiring-leg... Part 2: https://scotthelme.co.uk/complexities-chain-building-ca-infr... Part 3: https://scotthelme.co.uk/cross-signing-alternate-trust-paths... Part 4: https://scotthelme.co.uk/building-certificate-chains/
There's also the Let's Encrypt root migration that was postponed due to legacy devices: https://scotthelme.co.uk/lets-encrypt-postpone-isrg-root-tra...
Right now CT support is rough for things outside of browsers; it's a pretty fair bet that if you pick up a command line tool or library, it is not checking SCTs, and that makes those workflows vulnerable. If we flipped that, and the average command line tool or library did validate by default, it would dramatically alter the risk calculus for attackers.
I agree that more SCT validation across the ecosystem reduces the value of a mis-issued certificate to an attacker, but a lot of value still remains.
If 90% of clients did SCT validation, an attacker can still succeed against the 10% that don't, there's no herd immunity.
> In a world [where] CT logs and CAA records [exist]
And we are in that world. CT logs and CAA records exist. They are around. What you are implying you said is:
> In a world with CT logs and CAA records [and everyone/everything reads and validates them]
We are not in that world, and we probably won't enter that world for the next 15 to 20 years because we are also in a world where folks expect networked devices to be able to communicate (mostly) securely without constantly communicating with a centralized set of clearinghouses arbitrating "what is secure".
As we are discovering, our flawed systems may need broader rethinking, especially if we want secure communication (with all the epistemological ball of yarn that comes with it) without constant total centralization, which seems to be the approach-of-least-resistance lately.
So you create more surface area for vulnerability? We might already be at or close to the sweet spot. Security is hard.
> 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!
are you sure that this is not opening to more attack vector ?????
Your logic only makes sense if the user is your enemy.
The vendor loses the right to decide how my things are used the minute they take my money.
Bonus points if it's during a fake job interview.
Which legitimate accounts get banned for use in a VM?
That seems like an incredibly important thing I should know as I use legitimate accounts in VMs.
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.
But what about python pip and node and bun which bundle their own certs?
And then you'll have a compiled binary like Claude Code, which was built with bun, and has its vulnerable certificates bundled in, ignoring the system certs.
The fix can only come from the tool shipping an updated bundle, or if there's some way you can point it at the OS store once that's updated.
Just change your WiFi password, don’t give them the new one and don’t update them lol.
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.
I have two Google devices at home and both are compromised still. If Google can't handle pushing out a quick cert chain update, then I truly doubt other manufacturers can.
EDIT: seems its already happening? https://x.com/otomir23/status/2112697830687047918
At last, russians got better at installing wiretaps. Reminds me of the old joke that goes "How do you know there is a soviet made bug installed in your home?
There is an extra wardrobe."
EDIT: just whipped up a quick hacking session with DeepSeek and, indeed, Google hasn't updated the cert chain yet on these devices, I am sniffing everything with MITM! Let's see if I can put that to use and gain root. At the very least, a mock endpoint server is possible now for use with Home Assistant.
“eMudhra intermediate CA compromise” | 947 points | 19 hours ago | 408 comments
This statement is more discerning than anything else. It raises question about why this certificates exists in first place if not deployed since 2025. Is it deliberate attempt to do compromising of system?
In recent times, Indian Government is becoming quite rogue and don't follow the said procedures. So, it might be related to that as well.
There are two hard problems in computer science: naming things, cache invalidation, and off-by-one errors.
There are actually only two hard problems in computer science:
0) Cache invalidation
1) Naming things
4) Asynchronous callbacks
2) Off-by-one errors
3) Scope creep
6) Bounds checking
Most-nearly-prime number under 100 is.... 91.
13 x 7. You've either memorized that or you're going to have fun deciding it's not prime. And if you did times tables up to 13, congratulations, you're special.
because 10x7 = 70, i'm left with 21. everyone knows 21 is divisible by 7.
Meanwhile there are two less invasive changes that really ought to happen:
1. A clean way for things like curl and Python to start checking CT logs like Chrome does.
2. Name constraints. It’s long past time for the CAs of the world to have name constraints enforced. A CA that is not appropriate to use for .com should not work for .com. A CA that is not appropriate to use for .ae should not work for .ae. And the CA/B Forum should should requiring that all newly approved roots and all newly signed intermediates have appropriate name constraints.
2. I don't think such constraints would really work. My company might have 4 domains on different TLDs and then end up needing to use 4 different CAs. Geography doesn't really apply on the Internet.
I'm not sure it needs to map out this way. In the last few years people have gotten used to the idea that ACME means that the client interacts directly with the actual CA, but there's another model that at least used to be widespread: certificate brokers. Right now, I tell my ACME cliejnt to get me a Let's Encrypt certificate, and Let's Encrypt validates my request and makes it happen.
But what if I instead tell my ACME client to talk to a broker? The broker would arrange with various CAs for whatever portions of the overall namespace it supports, and it would give me TOS that those CAs find acceptable. And it would then forward my requests to appropriate backend CAs, and those backend CAs would (and would be required to by CA/B rules) validate my request. And I'd get a cert without particularly caring who the backend CA is.
The root stores would treat the backends as fully responsible for validation.
I don't know whether the current ACME model actually supports this very well. The tricky bits I can imagine mostly involve ACME account identification, CAA record details and dns-persist-01. If I authorize my ACME account (held with the broker) for my domain, the backend needs to be able to validate, in a manner that the broker cannot forge except to the extent that it's unavoidable. So if I have account 12345 (just an identifier), then I think the backend should be able to trust the broker's assertion that the client really did convince it (with replay protection) that it's the client for account 12345. But if I have an account where the account itself indicates a public key, then the broker should not be able to forge it.
In any case, I think it's vaguely ridiculous that, right now, the UK government has essentially no say in whether Let's Encrypt may issue certificates for .gov.uk domains. (This is just an example.)
Your CA would have a root cert per TLD. Alternatively, we get rid of non-cc TLD (and leave ccTLD only for truly geography-bound organizations, like governments).
Also if it's the same CA operating a bunch of different roots for different TLDs, they're likely to just make the same mistake that impacts them all. Sadly, I can't see anything like this working.
This is a simple point but there's something subtler underneath it. Strict name constraints are an obvious seeming improvement to the WebPKI. I like them too. but eMudhra isn't just an Indian sovereign CA; it's an important global commercial vendor. On the other thread about this incident, 'agwa pointed out that an eMudhra subsidiary does a lot of the certificates for US universities.
You're still going to end up with the same concentrations of risk, because large CAs are going to want to issue in the most popular domains.
Don't get me wrong, anything that ratchets up the difficulty of running a CA (without unduly burdening LetsEncrypt) is a positive as far as I'm concerned. I'm just saying these are hard problems.
In this case one cert gets defeated and you go the odds of that number being that low are 2^-384. Essentially impossible if it were randomly selected. It's much more likely you didn't choose that at random so I start guessing a bunch of other low numbers for your other certificates and find them quickly.
I have an insanely unlikely unique car licence plate number to sell you.
You would say the same of any seed I gave you. You've just artificially assigned this number with some sort of emotional importance.
"Playing roulette, in isolation after RED - RED - RED - RED - RED, there is not a higher chance of getting BLACK than RED in the next run. But in practice, one would be correct in concluding that it will probably be BLACK. The proof is that in our test, the next run gave BLACK".
Said differently, it was not particularly unlikely that the number would be 4. But maybe it got the attention of the person who decided to try assuming that it was a mistake, and they were indeed lucky.
I can think any number of programming mistakes that will result in a supposed (pseudo-)random number generator to be be biased to very small numbers. I have made such mistakes myself.
By any reasonable estimate, the probability of randomly picking a number below 256 is MUCH smaller than the probability of someone having made a mistake.
That doesn't make sense, does it?
> In this case one cert gets defeated and you go the odds of that number being that low are 2^-384.
It just happened that that particular number got the attention of a human, which was luck. But in terms of statistics, this number was not less likely than another one.
In short, raising the floor doesn’t really hurt the search space meaningfully.
In theory, all values would be equally random. In practice, some results are exceedingly more likely to occur when something's wrong with the algorithm.
While any given outcome of flipping a coin randomly N times is equally likely, if that series looks like [heads, heads, heads, heads, ...], then there's probably something other than pure random affecting the output.
That said, a sanity check on the value somewhere in the code would indeed have prevented this.
More generally, it is common to sample a bit string and use that as a seed for a PRG, from which the private key is generated. So in that case the range is [0, 2^k] and what matters is the quality of the randomness. Unfortunately high-quality randomness is not always available, especially for embedded devices and rack-mounted "appliances."
https://ubuntu.com/blog/emudhra-ca-compromise-fixes-availabl...
* It's absurd that Python, Go, or Node need their own certificate stores that need separate updates. (Probably OK for browsers because they seem very on top of updating them without user intervention.)
* This issue is especially bad when you consider deployment through containers, docker, etc. More parallel copies of vulnerable certificate stores. With docker volumes you could mount the host's certificates into the containers and get "update once" behavior but I doubt people are doing this.
* It wouldn't be too hard to implement CRLs against the OpenSSL certs as a script that runs from cron. I might end up doing this.
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...
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.
I guess they used (x `mod` 256) instead of (x `mod` (2^256)).
Previously: eMudhra intermediate CA compromise - https://news.ycombinator.com/item?id=50166579 - Oct 2026 (458 comments)
- 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.
> We have done some preliminary assessment, there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)
that sounds like the HSM is capable of generating keys in a range that is smaller than [1..group_order). such a feature makes no sense at all. or is this some kind of weird thing where people want to generate weak keys for 'testing' and HSM vendors have added such a strange feature. its actually satisfying to see someone get burned by this because such a feature should never exist and this is the reason why. if the HSM can generate keys in a smaller range (especially some arbitrary small range) then you are putting a lot of trust in the operators of the HSM. hopefully there are good audit logs and people actually check the audit logs every time keys are generated to make sure the keys being generated aren't from a special range.
the Audit part is scary. The same audit process might have cleared many other stuff.
https://www.einpresswire.com/article/951151580/emudhra-state...
On the other hand, can we not utilize that to also protect the IoT devices? Can we not create a MITM proxy on our own network that proxies all of our IoT devices's traffic and then forwards them to the trusted HTTPS, MQTTS, ... endpoints upstream? Since the proxy already revokes these bad certificates, the upstream traffic should be protected. We should be able to revoke any other bad certs in the the future as well.
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.
Some would argue the inherent moral hazard makes these opposing outcomes that cannot be achieved simultaneously.
Moral hazard describes situations where an entity is incentivized to take undue risk. With an upside of saving a single Indian endineers salary and a downside of destroying the entire company, it's safe to say the market wasn't incentivizing this. They were just stupid.
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).
Is it possible to convince the EU to say that, no, each one of your 27 member states isn't allowed to have a PKI? I don't think so.
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.
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.
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
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.
The write-up from eMudhra mentions something about wrapping/unwrapping ceremony failing.
Any sufficiently advanced stupidity is indistinguishable from malice.
Never assume unprofitable malice for what can adequately be explained by stupidity.
This is assuming the CT logs no longer issue SCTs for these CAs. If they do then you just need to the CT dance and publish that certificate there.
Of course this assumes the app/device isn't using certificate pinning.
Why wasn't this second spend by the parties accepting those certificates as valid before they were accepted?
In this case I wonder if this was an intentional wide open doorway to fraud
They literally were too lazy to type more than just a single '4'.
https://.mozilla.org/showbug.cgi?id=2083449
Here’s what I understand, every website sends some data encrypted by some key issued by CA and then the browser decrypts it first and then decrypts something in that message, to verify that Google.com, is google.com. I still don’t get why CA’s even exist, not sure what they are solving and how they’re doing it.
The first time you connect to google.com in your browser and get the google.com certificate, your web browser has to decide whether or not to trust that cert. It would be very complicated if every website on the internet had to prove its identity via some sort of out of band process, so web browsers, operating systems, etc all ship with a collection of trusted, institutionally-important certificates which are allowed to vouch for other certificates that aren't yet known to the browser, OS, etc.
Your browser (or whatever HTTPS client) basically says "I've never seen this certificate before, but Lets Encrypt (or Digicert or whoever) says they trust it and we trust Lets Encrypt, so we can treat it as trusted". You as a user are trusting that whatever verification/validation process the CA does is at least good enough to ensure that the owner of the domain is the entity giving you a certificate for that domain.
This is obviously not a perfect system. These CAs can be compromised and break the trust, and they have various levels of validation of the people and companies who come to them and ask to be included in their vouching network, etc. But its a compromise to make sure that users can connect to a wide variety of internet sites, using encryption, without needing to somehow decide whether they themselves trust the certificate provided by the website.
The most important thing to remember is that in most cases the CA is not vouching for the quality or integrity of the website - they are just vouching for whether the person/group who controls the domain/server is also the person/group providing the certificate for encrypted communication with the website. Its a protection against MITM attacks and snooping, not a protection against phishing or anything else that might happen once the connection is established.
The way it’s setup can any CA verify any website, so the weakest link of your CA basically allows an attacker to mimic any website you connect to?
This is the compromise. In exchange for having the ability to easily establish an encrypted connection to pretty much any public web service, the tradeoff is that the entire public internet's encryption is only as good as the operations of the weakest of the big public certificate authorities.
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.).
Why are browsers trusting CAs which issued zero certificates since their creation 1 year ago?
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"
No need for trustworthiness, then. /s
In all likelihood it is code that reads 1 byte from /dev/random, or reads 32 bytes but writes it into a 1 byte array, or something to that effect.
