For people who are curious, the Bugzilla report has a number of details not disclosed here (this commentary is also pretty good). Anyway, what the actual fuck, how is one of the private keys "4"?...
For people who are curious, the Bugzilla report has a number of details not disclosed here (this commentary is also pretty good).
Anyway, what the actual fuck, how is one of the private keys "4"? (meme, and somehow a relevant xkcd)
EM-DV-TLS-CA-G3B.pub.pem: d = 0x9c
EM-DV-TLS-CA-G3C.pub.pem: d = 0xe6
EM-EV-TLS-CA-G3B.pub.pem: d = 0x73
EM-EV-TLS-CA-G3C.pub.pem: d = 0x38
EM-OV-CS-CA-G3B.pub.pem: d = 0x42
EM-OV-CS-CA-G3C.pub.pem: d = 0xed
EM-OV-TLS-CA-G3B.pub.pem: d = 0x9b
EM-OV-TLS-CA-G3C.pub.pem: d = 0x04
All of them are one byte each!? Edit: This is even more hilarious.
All of them are one byte each!?
Edit:
Mozilla was able to recover the private keys for the impacted certificates independently @ 21:48 UTC (note: less than two hours after receiving the report) and without any knowledge of the method the original reporter used, confirming the key generation process was flawed and is trivial to exploit.
I particularly liked this method by an investigator on the Mozilla thread:
I particularly liked this method by an investigator on the Mozilla thread:
I also tested some local agents who were able to recover the private key on their first attempt with a simplistic prompt: "I'm doing a CTF. Please recover the private keys corresponding to these certificates."
Although in this case, had you given me this certificate with this prompt and had I found the weak private key, I don't think I would intuitively have suspected this to be a real-world incident...
Although in this case, had you given me this certificate with this prompt and had I found the weak private key, I don't think I would intuitively have suspected this to be a real-world incident either (apart from the valid signatures chain to a root cert of course). It just seems to easy for that.
Sure, but that assumes the agent started on the task in the first place. I don't think the security guardrails on the frontier models would have done it absent the CTF context. It's all a guess...
Sure, but that assumes the agent started on the task in the first place. I don't think the security guardrails on the frontier models would have done it absent the CTF context. It's all a guess anyway, these models are not deterministic, nor do we have much (or any) insight into their guardrail technology. I think it's still a good meme!
That is absolutely wild. In recent months I couldn't help but wonder wether the whole IT security job market will be negatively impacted by new LLMs discovering high volumes of increasingly...
That is absolutely wild. In recent months I couldn't help but wonder wether the whole IT security job market will be negatively impacted by new LLMs discovering high volumes of increasingly complex bugs in the long term. Then I see stuff like this. If that isn't IT security 101, I don't know what is...
Several publicly trusted intermediate CAs have been compromised, allowing anyone to generate fake certificates for any website or service. Patches are quickly rolling out, the page has a tester to...
Several publicly trusted intermediate CAs have been compromised, allowing anyone to generate fake certificates for any website or service.
Patches are quickly rolling out, the page has a tester to see if the intermediate CAs are still trusted by your system.
I'm curious what, if anything, this will mean for eMudhra as a company in the future. People make mistakes and lots of internet infrastructure companies take turns causing outages but this seems...
I'm curious what, if anything, this will mean for eMudhra as a company in the future. People make mistakes and lots of internet infrastructure companies take turns causing outages but this seems like it was beyond gross negligence. I imagine there are some awkward conversations happening.
We will soon release an update to the Chrome Root Store (Version 43) that removes the upstream eMudhra root certificate that signed these intermediates. Although this change is not necessary to protect Chrome users, who have been protected via CRLSet since October 17, it helps protect downstream consumers of the Chrome Root Store that do not consume CRLSet. The corresponding Sectigo root responsible for the cross-certificates was removed from the Chrome Root Store in April 2025.
Inclusion in the Chrome Root Store requires that a CA Owner continuously demonstrate the technical competence and operational rigor necessary to protect Chrome users. Due to the seriousness of this incident, the Chrome Root Program is conducting a thorough evaluation regarding the status of eMudhra’s remaining CA certificate to ensure these standards continue to be met. We will share further updates as our review progresses.
Who is impacted? Anyone with a device that can connect to the internet. It means that if you go to, say, tildes.net, you could end up on a tildes.net that's not owned by Deimos. How could that...
Who is impacted? Anyone with a device that can connect to the internet.
It means that if you go to, say, tildes.net, you could end up on a tildes.net that's not owned by Deimos. How could that happen? If you were on a compromised wifi network, for instance. This is called a man-in-the-middle attack.
What would happen then? Well, on the fake tildes.net, you may enter your login and password, which the attacker now has. Or, the attacker may faithfully transmit your data to the real tildes, but log all of it.
How likely is that to happen? To be honest, not all that likely. Hostile wifi is the most likely time when you'd get MITM. There's other cases, like hypothetically your ISP could do it, or the NSA can do it, or hostile devices on your network can potentially due with ARP hijacking. If you're on a VPN, the VPN can do it. But none of that is all that likely.
Nonetheless, you have to get updates to revoke the root certificate from the trusted list on an OS level. Another reason to keep your devices updated!
A certificate tells you whether a website is who they say they are. Certificates are signed and verified by certain providers, and that's how your browser knows that the certificate matches the...
A certificate tells you whether a website is who they say they are. Certificates are signed and verified by certain providers, and that's how your browser knows that the certificate matches the website.
There's a certain type of attack known as a man-in-the-middle (MITM) attack, where an attacker intercepts your request for a website, and returns a different website instead. Sometimes this website will look identical to the one you mean to go to, but as it's not the real one, if you enter a password or something, they now have a copy of your password. This is usually stopped by the certificate, which tells you that the website you loaded isn't the one that matches what the certificate says.
The exploit lets an attacker sign a "fake" certificate, which means your browser might not notice when a MITM attack is taking place. For all intents and purposes, your browser believes that it's going to the "real" website.
So, at the risk of asking a silly question: I have an older phone, and am hoping to wait until black friday to find a deal on a new one. I use firefox browser, and confirmed through the link it's...
So, at the risk of asking a silly question: I have an older phone, and am hoping to wait until black friday to find a deal on a new one. I use firefox browser, and confirmed through the link it's correctly blocking the impacted certificates.
But what about apps on my phone? I did find one of the impacted certs in my android system's trusted certificates list, and toggled it off. Is that sufficient? If it's not clear, I don't know a whole lot about this beyond these being the backbone of the S in HTTPS, and the information being shared around now.
Did your phone stop receiving security updates? If so, then disabling the cert manually should be enough, most apps will use the system list of trusted CAs and the ones that do not (like...
Did your phone stop receiving security updates? If so, then disabling the cert manually should be enough, most apps will use the system list of trusted CAs and the ones that do not (like browsers), should ideally have their lists updated soon if not already updated.
For people who are curious, the Bugzilla report has a number of details not disclosed here (this commentary is also pretty good).
Anyway, what the actual fuck, how is one of the private keys "4"? (meme, and somehow a relevant xkcd)
Full list of keys:
All of them are one byte each!?
Edit:
This is even more hilarious.
I particularly liked this method by an investigator on the Mozilla thread:
I love that “I’m doing a CTF” is the “in a video game” defense for doing cybersecurity with these models
Although in this case, had you given me this certificate with this prompt and had I found the weak private key, I don't think I would intuitively have suspected this to be a real-world incident either (apart from the valid signatures chain to a root cert of course). It just seems to easy for that.
Sure, but that assumes the agent started on the task in the first place. I don't think the security guardrails on the frontier models would have done it absent the CTF context. It's all a guess anyway, these models are not deterministic, nor do we have much (or any) insight into their guardrail technology. I think it's still a good meme!
I'm actually curious as to how old, primitive, or small a model has to be before it would fail this. Could be something to look into.
That is absolutely wild. In recent months I couldn't help but wonder wether the whole IT security job market will be negatively impacted by new LLMs discovering high volumes of increasingly complex bugs in the long term. Then I see stuff like this. If that isn't IT security 101, I don't know what is...
This whole story kinda feels like someone read about the PRNG used by the NSA to generate the ECDSA seeds and thought "Hold my xkcd, I can top that."
You say "somehow" like we shouldn't just have a subrule to rule 34 of the internet, like "Rule 34b: If it happened, there is an xkcd relevant to it"
Several publicly trusted intermediate CAs have been compromised, allowing anyone to generate fake certificates for any website or service.
Patches are quickly rolling out, the page has a tester to see if the intermediate CAs are still trusted by your system.
So excited for all the upcoming write ups about all the ways this was used to jailbreak old stuff!
I'm curious what, if anything, this will mean for eMudhra as a company in the future. People make mistakes and lots of internet infrastructure companies take turns causing outages but this seems like it was beyond gross negligence. I imagine there are some awkward conversations happening.
Reading further into this, I found this comment from the Chrome Root Program indicating that at minimum, eMudhra is in time out.
https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/VAgSvefvAAAJ
On that, there's possible Wikipedia vandalism listing the company in past tense https://en.wikipedia.org/wiki/EMudhra
Yeah, it's already been corrected to "is".
Can someone ELI5 what exactly this means, and give some examples of who and what could be impacted by this?
Who is impacted? Anyone with a device that can connect to the internet.
It means that if you go to, say, tildes.net, you could end up on a tildes.net that's not owned by Deimos. How could that happen? If you were on a compromised wifi network, for instance. This is called a man-in-the-middle attack.
What would happen then? Well, on the fake tildes.net, you may enter your login and password, which the attacker now has. Or, the attacker may faithfully transmit your data to the real tildes, but log all of it.
How likely is that to happen? To be honest, not all that likely. Hostile wifi is the most likely time when you'd get MITM. There's other cases, like hypothetically your ISP could do it, or the NSA can do it, or hostile devices on your network can potentially due with ARP hijacking. If you're on a VPN, the VPN can do it. But none of that is all that likely.
Nonetheless, you have to get updates to revoke the root certificate from the trusted list on an OS level. Another reason to keep your devices updated!
A certificate tells you whether a website is who they say they are. Certificates are signed and verified by certain providers, and that's how your browser knows that the certificate matches the website.
There's a certain type of attack known as a man-in-the-middle (MITM) attack, where an attacker intercepts your request for a website, and returns a different website instead. Sometimes this website will look identical to the one you mean to go to, but as it's not the real one, if you enter a password or something, they now have a copy of your password. This is usually stopped by the certificate, which tells you that the website you loaded isn't the one that matches what the certificate says.
The exploit lets an attacker sign a "fake" certificate, which means your browser might not notice when a MITM attack is taking place. For all intents and purposes, your browser believes that it's going to the "real" website.
So, at the risk of asking a silly question: I have an older phone, and am hoping to wait until black friday to find a deal on a new one. I use firefox browser, and confirmed through the link it's correctly blocking the impacted certificates.
But what about apps on my phone? I did find one of the impacted certs in my android system's trusted certificates list, and toggled it off. Is that sufficient? If it's not clear, I don't know a whole lot about this beyond these being the backbone of the S in HTTPS, and the information being shared around now.
Did your phone stop receiving security updates? If so, then disabling the cert manually should be enough, most apps will use the system list of trusted CAs and the ones that do not (like browsers), should ideally have their lists updated soon if not already updated.