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."
I don't know, when I run a password cracker, I always start with a brute force pass of very short passwords. Doing so adds a negligible amount of time to the crack, and its surprising how many short passwords you'll find in systems that permit them.
Archive is a nice solution in between just letting it rot on the vine forever and deleting it. Leaving it open doesn't immediately signal to users that the codebase is no longer in development, youd have to check when the last commit was. And even then, that doesn't tell you much. Is this so simple of an app that there's really nothing to patch or upgrade for long periods? A python script that converts some legacy file format into an open one might effectively be complete, there's nothing left to add or fix and there's no real threat vector to exploit. Or is this a cutting edge app that someone committed daily for years but now hasn't moved in a year.
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.
Competence is difficult to check systematically. The problem is in the auditing process. The CA auditors check a much shorter list than an application that needs FIPS compliance. They just check that the CA is using a FIPS compliant key generator, and then basic things like following a logged, standard, multi person process.
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.
Certificate transparency requirements effectively take the power away from certificate authorities.
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.
I agree this is a burden placed on domain owners, but who else can know if a certificate for my domain 'scotthelme.co.uk' was supposed to be issued other than me, the owner of 'scotthelme.co.uk'?
Do you have any info on the malicious CT logs? I'd be interested to read something on that!
There are chains of trust which are established for SSL certs, centered around the idea that if we can believe Mozilla et al. that the server responding is who they claim they are. Up until now, that is good enough to establish the trust needed to accept the 2 keys in the connection are connected, and then a secure connection could be established to the host server.
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.
> 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!
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.
It's easy enough to apt upgrade, and curl shows it's not vulnerable.
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.
Yep, it's a long tail. Anything that ships it's own CA bundle will ignore whatever you fix at the OS level. Those bundles are generally root-only and don't have revocation checking, so they can't block a bad intermediate cert.
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.
You can't hardly use the TVs then. I've seen TVs that don't let you use the HDMI port without it being connected if you have a streaming dongle connected. Hopefully that practice has mostly died off now (Samsung used to do this on some models, iirc), but it's still a risk and only kicks the can down the road a bit.
> > 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.
> how many of these devices will have the compromised CA root certificate in place?
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.
Okay hear me out. People are complaining about unpatcheable IOT device and thats indeed concerning. But can’t we use the bad keys to generate seemingly value certificates that can be used to jailbreak these devices?
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?
Yeah this is absolutely possible, and while they are a few good opportunities like this, it also means that someone else can decrypt all of your traffic in the same way.
I really hope someone manages to root the Google Home speakers. Been waiting for ages to be able to repurpose them for Home Assistant integration!
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.
"Importantly, none of the affected intermediate CAs were deployed in production, with the exception of one. Furthermore, none of these intermediate CAs, including the one deployed in production, have issued any end-entity certificates. This has been confirmed through our internal analysis and corroborated by publicly available Certificate Transparency records on crt.sh."
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.
I wonder if anyone wants to over-analyze this joke to come up with the best candidates for the number? 57 falls too easily to the quick divisibility by 3 trick, IMO. (I realize over-analyzing jokes always makes them unfunny but we can pick the best number here and nobody has to know).
it doesn't have to be and it actually never is: this isn't RSA, it's an elliptic curve algorithm. if you'd have read the article, you'd have understood this
For all that DNSSEC is crap, DANE would at least mean that a domain is only vulnerable to failures of the authorities relevant to the domain.
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.
1 already exists. You don't check the ctlogs; the ctlogs as their signed timestamp to the certificates. All you need to verify that a certificate has been published is to verify the timestamp signatures.
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 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.)
> My company might have 4 domains on different TLDs
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).
This is everyone's first pitch for why DANE would improve the WebPKI. But it doesn't make sense as risk management. It assumes that the most important TLD operators, .COM especially, are trustworthy. But we know .COM is not trustworthy, at all. And it gets worse when you leave the US. In much of the world, state organizations have explicit de jure control over all the popular top level domains.
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.
My oven (which has a camera and WiFi, don't ask, it's a great oven otherwise and doesn't exist without WiFi) received a software update this morning. I can't help but wonder if it's related.
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.
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.
If the application uses p11-kit, or a TLS library that uses p11-kit such as OpenSSL, NSS, or GnuTLS, then Flatpak should automatically give it access to the host system's CA certificates.
Quick question for the crypto experts. I thought that the goal of a true random number generator was that all values between 0 and MAXCOUNT are equally likely, and therefore all private keys between those values are equally likely. Is this not true? If people are going to attempt to brute force your key, don't you want the floor to start at 0? If the floor is higher, won't the brute force start higher too?
It's not that 4 isn't a valid seed (though insanely unlikely) it's that once I know your values weren't picked randomly because I guessed one of them I can easily figure out the others.
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.
Imagine you have a 3 digit PIN code. That’s 1,000 options to brute force. If you remove 000-009 as “too weak”, you still have 99% of the search space available. These numbers scale favorably as the private key size gets bigger.
In short, raising the floor doesn’t really hurt the search space meaningfully.
It also acts as a test case. "Hey seed-generator, give me a random number between 0 and a gazillion." "Does 4 sound good?" "No, it sounds like you're obviously broken."
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.
You are technically correct, the best kind of correct! Though I have a feeling we'll never see a 384-bit CSRNG generate 352 0-bits in a row in this Universe's lifetime.
That said, a sanity check on the value somewhere in the code would indeed have prevented this.
Yes, what matters is the size of the range, not the bounds on the range. Also keep in mind that in some cases private keys are not uniformly sampled from a range of integers; for example RSA keys, which are sampled from prime numbers.
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."
* 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.
I reckon that was an attempt to fend off the enemy. "Everyone expects us to set 196 bits of entropy, but you know what they won't expect? A single byte!"
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.
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"?
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.
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.
I'm wondering how many other private keys might be cropped to 32, 64 or 128 bit and much weaker than we think. Seems like nobody tested it yet. Otherwise the 8 bit would've been found within minutes.
- 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)
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)...
Scary perhaps, but not surprising. Most IT "audits" and security reviews are little more than performative box checking activities. I'm sure their documentation and screenshots looked great.
I thought CAs automatically filtered out really low keys. There's a great Suckerpinch video (https://youtu.be/M1si1y5lvkk) about trying to purposely make the least secure HTTPS page possible, and Tom initially tried to choose a laughably-low number as the key, but the CA automatically rejected it.
After my shock and anger subside, I can think more clearly now. I see many have mentioned using this to perform MITM on the IoT devices.
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.
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.
The company had a valuation of about $500million USD (converted from INR) before the incident. Now it's likely worthless, because of an incident that could have been prevented by hiring one competent person.
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.
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.
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.
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).
My impression is "why" is political, with regulations like EU's eIDAS and other national digital sovereignty efforts setting the rules. It's not even WebTrust that's the target in most cases, it's the ETSI EN 319 series and ISO 21188.
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.
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?
Predicting more LAN devices come pre-installed with a variety of private VPN options and an option to route all traffic from specific devices through that.
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).
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".
I’ve tried asking Opus 5.5 but I don’t fully get the mechanics of this Certificate Authority stuff, wonder if someone can dumb it down here for me.
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 real problem the CAs try to solve is, basically, being a trusted middleman who vouches for other certificates.
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.
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.).
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?
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.
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.
I would be shocked if this was anything other than a bug. A CA already has the power to issue MITM certificates, so what reason would a CA have to deliberately generate bad keys?
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.
new email from wayne, who is the original reporter:
"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 must say, if I was writing a password cracker, I probably would not think to actually start at "1".
Of course not, we start at negative zero.
https://en.wikipedia.org/wiki/Signed_zero
1 reply →
I don't know, when I run a password cracker, I always start with a brute force pass of very short passwords. Doing so adds a negligible amount of time to the crack, and its surprising how many short passwords you'll find in systems that permit them.
You should start at "" or 0, not "1".
Security through incredulity
1 reply →
Welp, there goes that password
> https://github.com/google/paranoid_crypto
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? :)
Archive is a nice solution in between just letting it rot on the vine forever and deleting it. Leaving it open doesn't immediately signal to users that the codebase is no longer in development, youd have to check when the last commit was. And even then, that doesn't tell you much. Is this so simple of an app that there's really nothing to patch or upgrade for long periods? A python script that converts some legacy file format into an open one might effectively be complete, there's nothing left to add or fix and there's no real threat vector to exploit. Or is this a cutting edge app that someone committed daily for years but now hasn't moved in a year.
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.
Archived means it’s still available but signals that it won’t be developed.
Last commit was 2 years ago anyway.
I am sure the NSA will keep checking on our behalf.
You can still use a read-only archive.
I'm guessing this is the code:
https://github.com/google/paranoid_crypto/blob/main/paranoid...
I have to be honest, that hasn't stopped me from trying!
In retrospect, having 100 trusted certificate authorities might have been excessive.
In retrospect, not having a tiny competency check may have been an oversight.
Competence is difficult to check systematically. The problem is in the auditing process. The CA auditors check a much shorter list than an application that needs FIPS compliance. They just check that the CA is using a FIPS compliant key generator, and then basic things like following a logged, standard, multi person process.
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.
3 replies →
That really depends how you define "trusted certificate authorities".
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!
Certificate transparency requirements effectively take the power away from certificate authorities.
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.
I agree this is a burden placed on domain owners, but who else can know if a certificate for my domain 'scotthelme.co.uk' was supposed to be issued other than me, the owner of 'scotthelme.co.uk'?
Do you have any info on the malicious CT logs? I'd be interested to read something on that!
2 replies →
How are they trusted if they can just generate any key they like in their back room?
"Trusted" means how people treated them, it doesn't mean the extent to which they deserved trust.
1 reply →
There are chains of trust which are established for SSL certs, centered around the idea that if we can believe Mozilla et al. that the server responding is who they claim they are. Up until now, that is good enough to establish the trust needed to accept the 2 keys in the connection are connected, and then a secure connection could be established to the host server.
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.
1 reply →
That's the thing about trust -- in order to get into the root key store for windows, chrome, linux, etc they were trusted not to do that.
they violated that trust.
Correct, we only need zero.
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.
77 replies →
or, perhaps you need more so that one being stupid doesn't effect so much.
Each CA is like a padlock locked in series with other padlocks. The weakest padlock is the only one that matters.
7 replies →
> 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.
1 reply →
> 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!
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.
"let the user install their own certs should not exist"
are you sure that this is not opening to more attack vector ?????
19 replies →
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.
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.
It's easy enough to apt upgrade, and curl shows it's not vulnerable.
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.
Yep, it's a long tail. Anything that ships it's own CA bundle will ignore whatever you fix at the OS level. Those bundles are generally root-only and don't have revocation checking, so they can't block a bad intermediate cert.
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.
If you just take them offline you can do this without having to rush.
Just change your WiFi password, don’t give them the new one and don’t update them lol.
You can't hardly use the TVs then. I've seen TVs that don't let you use the HDMI port without it being connected if you have a streaming dongle connected. Hopefully that practice has mostly died off now (Samsung used to do this on some models, iirc), but it's still a risk and only kicks the can down the road a bit.
2 replies →
Just imagine how much stuff you're going to be able to MiTM now!!
Some of them seem to do some cert pinning
> > 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.
> how many of these devices will have the compromised CA root certificate in place?
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.
1 reply →
[dead]
Okay hear me out. People are complaining about unpatcheable IOT device and thats indeed concerning. But can’t we use the bad keys to generate seemingly value certificates that can be used to jailbreak these devices?
EDIT: seems its already happening? https://x.com/otomir23/status/2112697830687047918
>yandex-station-lite
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."
Yeah this is absolutely possible, and while they are a few good opportunities like this, it also means that someone else can decrypt all of your traffic in the same way.
Yeah, it's happening in the wild already. Seen more cases like that.
I really hope someone manages to root the Google Home speakers. Been waiting for ages to be able to repurpose them for Home Assistant integration!
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.
Related: https://news.ycombinator.com/item?id=50166579
“eMudhra intermediate CA compromise” | 947 points | 19 hours ago | 408 comments
"Importantly, none of the affected intermediate CAs were deployed in production, with the exception of one. Furthermore, none of these intermediate CAs, including the one deployed in production, have issued any end-entity certificates. This has been confirmed through our internal analysis and corroborated by publicly available Certificate Transparency records on crt.sh."
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.
Of COURSE it's easy to crack, 4 isn't even prime!
In their defense, they were probably targeting the Mersenne prime 2^2 - 1 and just made a typo.
> In their defense, they were probably targeting the Mersenne prime 2^2 - 1 and just made a typo.
There are two hard problems in computer science: naming things, cache invalidation, and off-by-one errors.
5 replies →
ok, it's joke. but for those who don't get it: elliptic curves don't need primes
It’s really impressive no one caught their three previous private key values
I suspect they did but it wasn't publicised.
They should have gone with 57. Everyone knows it's prime.
I wonder if anyone wants to over-analyze this joke to come up with the best candidates for the number? 57 falls too easily to the quick divisibility by 3 trick, IMO. (I realize over-analyzing jokes always makes them unfunny but we can pick the best number here and nobody has to know).
3 replies →
Alex? You're alive after all?
https://xkcd.com/221/
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
it doesn't have to be and it actually never is: this isn't RSA, it's an elliptic curve algorithm. if you'd have read the article, you'd have understood this
The number 4 is very famous.
https://xkcd.com/221/
Hey, that's the same combination I have on my luggage!
Good job the Earth doesn't have an air shield protected by this byte or we'd be Skroob'd.
For all that DNSSEC is crap, DANE would at least mean that a domain is only vulnerable to failures of the authorities relevant to the domain.
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.
1 already exists. You don't check the ctlogs; the ctlogs as their signed timestamp to the certificates. All you need to verify that a certificate has been published is to verify the timestamp signatures.
1. They could do this now, the implementation exists publicly, but I think it would be better at the OS level like upki for revocation: https://discourse.ubuntu.com/t/addressing-linuxs-missing-pki...
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 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.)
> My company might have 4 domains on different TLDs
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).
1 reply →
This is everyone's first pitch for why DANE would improve the WebPKI. But it doesn't make sense as risk management. It assumes that the most important TLD operators, .COM especially, are trustworthy. But we know .COM is not trustworthy, at all. And it gets worse when you leave the US. In much of the world, state organizations have explicit de jure control over all the popular top level domains.
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.
My oven (which has a camera and WiFi, don't ask, it's a great oven otherwise and doesn't exist without WiFi) received a software update this morning. I can't help but wonder if it's related.
Either that or it's running PHP
You'll know this evening when it demands $10 to release your meal.
I see you love technology.
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.
The more cynical among us think that is part of it. Remember when Bush Jr. became a bumbling idiot for a few years?
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.
If the application uses p11-kit, or a TLS library that uses p11-kit such as OpenSSL, NSS, or GnuTLS, then Flatpak should automatically give it access to the host system's CA certificates.
Quick question for the crypto experts. I thought that the goal of a true random number generator was that all values between 0 and MAXCOUNT are equally likely, and therefore all private keys between those values are equally likely. Is this not true? If people are going to attempt to brute force your key, don't you want the floor to start at 0? If the floor is higher, won't the brute force start higher too?
It's not that 4 isn't a valid seed (though insanely unlikely) it's that once I know your values weren't picked randomly because I guessed one of them I can easily figure out the others.
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.
> It's not that 4 isn't a valid seed (though insanely unlikely)
I have an insanely unlikely unique car licence plate number to sell you.
> Essentially impossible if it were randomly selected.
You would say the same of any seed I gave you. You've just artificially assigned this number with some sort of emotional importance.
7 replies →
Imagine you have a 3 digit PIN code. That’s 1,000 options to brute force. If you remove 000-009 as “too weak”, you still have 99% of the search space available. These numbers scale favorably as the private key size gets bigger.
In short, raising the floor doesn’t really hurt the search space meaningfully.
It also acts as a test case. "Hey seed-generator, give me a random number between 0 and a gazillion." "Does 4 sound good?" "No, it sounds like you're obviously broken."
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.
It seems that somebody / something only created a single byte of randomness for each certificate.
You are technically correct, the best kind of correct! Though I have a feeling we'll never see a 384-bit CSRNG generate 352 0-bits in a row in this Universe's lifetime.
That said, a sanity check on the value somewhere in the code would indeed have prevented this.
Yes, what matters is the size of the range, not the bounds on the range. Also keep in mind that in some cases private keys are not uniformly sampled from a range of integers; for example RSA keys, which are sampled from prime numbers.
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."
IIRC in RSA the key, a prime number, is selected between 2^(bits-1) and 2^bits, or iow it always starts with a 1₂.
For those running Ubuntu, the following page tells you what to do. It's two commands:
https://ubuntu.com/blog/emudhra-ca-compromise-fixes-availabl...
https://bugzilla.mozilla.org/show_bug.cgi?id=647959
This issue is highlighting a few things for me:
* 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.
Someone used the Dilbert random number generator. https://www.random.org/analysis/
They clearly used the one from XKCD.
https://xkcd.com/221
Maybe they are a CIA front like CryptoAG
I reckon that was an attempt to fend off the enemy. "Everyone expects us to set 196 bits of entropy, but you know what they won't expect? A single byte!"
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.
This question seems to be answered in another comment now: https://news.ycombinator.com/item?id=50180284
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"?
> 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).
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.
4 replies →
Related ongoing thread: Your MCU Likely Escaped the eMudhra Intermediate CA Compromise - https://news.ycombinator.com/item?id=50166579 - Oct 2026 (458 comments)
That's some criminal negligence right there.
8 bits is crazytalk!
“4”
hey chatgbg what is a “private key”
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.
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”.
Isn't 4 simply 2 bits?
Silly 2-bit outfit.
Maybe it's 3 bits.
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.
1 reply →
I made test.key4.lol if you want to quickly check if your device/browser is vulnerable still.
I'm wondering how many other private keys might be cropped to 32, 64 or 128 bit and much weaker than we think. Seems like nobody tested it yet. Otherwise the 8 bit would've been found within minutes.
It’d be absurd to believe nobody tested these, and that no individuals involved in relevant standards bodies were aware of this weakness.
Those 8 bit certs were out for over a year, in the public. So nobody tested them. At least no independent security researcher.
We live in an absurd universe, the absurd should be expected.
"absolutely no way that there is a $100 bill on the sidewalk- if there were, somebody would have picked it up already"
If you've got the compute power, it's easy enough to have a go at it!
Is it legal? I thought the DMCA protects flimsy security of this kind by making it illegal to check if its flimsy.
5 replies →
It feels like they chose the private keys by hand.
Artisanal cryptography. Hand-picked private keys salted with organically sourced nonces.
Brooklyn-based. Guy in overalls and a waxed mustache hands out the bits.
1 reply →
Made with love
Sharing is caring after all.
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.
All the numbers also have digits going from left to right on a keyboard. I think the manual "random" input theory is plausible.
2 replies →
Some error code being used? FIPS mode gone wrong?
There's a beginning of an explanation in the mozilla bugrepor thttps://bugzilla.mozilla.org/show_bug.cgi?id=2083449
Thanks. The relevant quote:
> 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)
1 reply →
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.
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)...
https://xkcd.com/221/
>> "These roots and issuing CAs have gone through independent audits for two years in a row and have been in browser trust lists since mid-2025".
the Audit part is scary. The same audit process might have cleared many other stuff.
https://www.einpresswire.com/article/951151580/emudhra-state...
Scary perhaps, but not surprising. Most IT "audits" and security reviews are little more than performative box checking activities. I'm sure their documentation and screenshots looked great.
I thought CAs automatically filtered out really low keys. There's a great Suckerpinch video (https://youtu.be/M1si1y5lvkk) about trying to purposely make the least secure HTTPS page possible, and Tom initially tried to choose a laughably-low number as the key, but the CA automatically rejected it.
After my shock and anger subside, I can think more clearly now. I see many have mentioned using this to perform MITM on the IoT devices.
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.
Yeah, this would work.
Thank you! Working on the proxy now ...
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.
> promise security and.. make a profit
Some would argue the inherent moral hazard makes these opposing outcomes that cannot be achieved simultaneously.
The company had a valuation of about $500million USD (converted from INR) before the incident. Now it's likely worthless, because of an incident that could have been prevented by hiring one competent person.
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.
Like a web-of-trust model?
Could HN start feeding submissions through Pangram so us human readers don't have to suffer with reading the nauseating AI-prose?
Count yourself lucky - compared to Claude's prose, this is fairly readable.
It reads fine to me. If it is AI, I'd like to know which one so I can use it too.
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.
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.
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.
3 replies →
[dead]
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).
My impression is "why" is political, with regulations like EU's eIDAS and other national digital sovereignty efforts setting the rules. It's not even WebTrust that's the target in most cases, it's the ETSI EN 319 series and ISO 21188.
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.
The needful is complete
eMudhra explanation : https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c11
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.
Given the usefulness of this to anybody who knew about it between the ceremony and now - assume malice.
If I was to leak a private key for malicious use, I would leak a good key that only I know.
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?
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.
8 replies →
Any sufficiently advanced malice is indistinguishable from stupidity.
The reverse is also true:
Any sufficiently advanced stupidity is indistinguishable from malice.
Never assume stupidity for what can adequately be explained by profitable malice.
Never assume unprofitable malice for what can adequately be explained by stupidity.
This does not look like blunder; more like espionage. The bigger guys are throwing emudra under the bus.
“espionage” would involve a private key shared with the three-letter agencies, not a key anyone could crack in seconds
anyone = themselves. The key ceremony is supposed to be nuke launch level secure. That 4 pass many eyes.
1 reply →
> One of eMudhra's certificate authority private keys is the number 4.
https://imgs.xkcd.com/comics/random_number.png
Predicting more LAN devices come pre-installed with a variety of private VPN options and an option to route all traffic from specific devices through that.
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).
You also need to block access to the approved CT list until it fails open after 70 days.
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.
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
Test your browser and update your system's certificates: https://emudhra.we-have-a-problem.com/
Anything to update/check for Macs running on various versions of the OS?
Apple has blocked the intermediates, so updating is good enough to resolve it for you.
> 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?
It's a valid question at this point.
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".
Well, so what now? It's not like I have these in my system CA store, they're just intermediaries cross-signed by sectigo.
You can add the intermediate CA to your block list, presumably the distros will do this
Looks like archlinux already did. After update my fake st*pe.com cert no longer verifies. Ufff.
1 reply →
All the numbers were under 384. Surely they couldn't have ...
All the numbers were under 256. Surely they did.
Never attribute to malice what can be explained by ignorance?
In this case I wonder if this was an intentional wide open doorway to fraud
This wasnt malice its was laziness.
They literally were too lazy to type more than just a single '4'.
Either that or they intentionally wanted to create a publicly-accessible backdoor, with plausible deniability of laziness
I love how this article explains multiplication... very carefully.
Shakti de. This should be firm-ending for them but I fear it won't be.
This is amazing! I've already been able to grab firmware images for two locked down ESP32-using devices that I struggled to jailbreak before.
Bugzilla bug in question:
https://.mozilla.org/showbug.cgi?id=2083449
https://bugzilla.mozilla.org/show_bug.cgi?id=2083449
Man in the middle just for the love of the game
https://xkcd.com/221/
Literally the tutorial they used
I think this might be proprietary source code, did you get permission to share this?..
I’ve tried asking Opus 5.5 but I don’t fully get the mechanics of this Certificate Authority stuff, wonder if someone can dumb it down here for me.
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 real problem the CAs try to solve is, basically, being a trusted middleman who vouches for other certificates.
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.
I see thanks for the explanation.
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?
2 replies →
I have an older blog post that goes in to a little detail on what a CA is and how it works: https://scotthelme.co.uk/impending-doom-root-ca-expiring-leg...
From the author of "Passkeys are not a trap", and written by Claude from the looks of it...
Hey what's wrong with Passkeys?!
What the chances there’s another CA key out there with something like unix time as the key?
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.).
Someone else has published usable .key files here: https://github.com/Fluepke/emudrahahahahaha
> 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?
These are intermediate roots, signed by trusted root certs, so the trust from your OS or browser is implicit to the roots it trusts.
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?
1 reply →
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.
It's an interesting idea, but how would a user make that decision on who to trust? As in, what 'things' could we look at to make that call?
Doesn't ACME+CT solve this threat?
My izzat is down right now.
hey, at least it was easy to remember...
Can't lose your key if it's easy to remember!
Another very unfortunate even next to the php, fun times we are living in.
[flagged]
[flagged]
[flagged]
[dead]
This has to be a backdoor planted by hackers, mess with the key gen, say is all good. Must be known since issuance.
I wouldn't be surprised if we learn in the near future, that this was deliberate.
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.
But that would be obviously intentional. Much more plausible deniability with 0x4.
Why are many of them, suspicious?
6 replies →
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.
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.
Why would it be?
Do I honestly need to enumerate what you can do if you have the keys for a CA?
5 replies →
Sounds more like extremely sloppy procedures. Which depressingly I doubt are unusual among CAs.
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.
2 replies →
I would be shocked if this was anything other than a bug. A CA already has the power to issue MITM certificates, so what reason would a CA have to deliberately generate bad keys?
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.