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
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).
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.
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
- 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.
Oh wow, that is even more damning. Only 146 out of the possible 256 keys have this property. You only have about a 1% chance to get that 8 times in a row (A little more than 1% if sampling with replacement and a little less if sampling without. You'd expect them to at least not use the exact same key twice but at this point???).
The fact that there are more than the "4" one, and all the low numbers are below 384 (384 being the bits for private key) makes me think whoever was creating these thought "Oh a random number between 1-384" let me choose... 4! (156, 230, 115, 56, 66, 237, 155)...
> 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)
`a flaw in the code resulted in the second pair of keys being created onboard which were weaker`
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.
Maybe it follows openssl keygen process: you first generate private key, then export public key from it as k*G. In case of ecc private key is a random number, streamed from RNG, but RNG doesn't know for what purpose you generate a random number and can generate a number of any size.
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.
The key generator is a FIPS certified HSM that created a strong key. They ran the key through some stupid script that zeroed out all the bytes except the last one. The point of a full FIPS audit is to check that you don’t do anything stupid with crypto like try to implement anything yourself and that you only use certified implementations. But that standard apparently doesn’t apply to CA’s. They only have to use FIPS modules to generate the keys but can do whatever idiocy they want after that. Therein lies the real problem.
Yes, because as we are seeing with this incident, plenty of things don’t check CT logs (and thus can still be hacked if CT isn’t published for bad certs), and CAA records are fundamentally advisory.
Scan a QR code when you open the 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. If you ever see something that you can independently verify is false, you untrust whichever keys signed it and take it up with their holders.
It does protect against MITM. A man in the middle can pass the content along or they can refuse to do so but they can't forge a signature.
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.
> So where do you get this signature exactly so they don't MITM you the first time?
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.
Well if you find unsigned content, you should probably just not show it to the user at all.
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'd argue that you should push this into the application layer, so rather than scoping the keys to domain names you scope them to something relevant to whatever the user authentically trusts. So the user (or OS) would pass an object at runtime to indicate which peers they want the app to trust today.
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. 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.
This way your application can work over alternative transport layers: carrier pigeons, whatever, and doesn't break just because the other party has a different names 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.
In the modern day that's arguably fine, most users only interact with a few actual companies online (though many of them haphazardly use dozens of domains and dozens of unrelated certificates).
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.
Sure, but if "scan this and do FaceID and click 'Yes, I trust this CA'" was as common as "Accept terms & conditions" or "Allow necessary cookies" or (the worst:) "Check your email for the six-digit code" then people would be installing CAs so often that everyone would have dozens of extremely shady ones installed at all times.
My intent is to provide users with the ability to revoke trust if in a source of information if they realize it is malicious, and to gossip that revocation among their peers.
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.
In practice we have Certificate Transparency Logs that let us check whether a CA has issued a certificate for a domain you control without you asking them to.
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.
I think someone explained that only browsers and maybe some applications check the CT logs in the first place. Most applications don't, so someone can impersonate any URL an application connects to and the attacker doesn't have to publish to a CT log.
How would certificate transparency logs have helped here though? If the private key leaks and anyone can mint a valid certificate that gets accepted, those logs aren't going to reveal it.
If an attacker takes the CA key and issues a valid certificate, but does not log it to CT, mainstream browser clients will not accept it.
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.
Zero would be hard but we could have signed CA cert put into DNS record and from that the org itself can create the certs for that domain.
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
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 HTTP. ..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.
Which leads to users that are not that technically savvy learning to always click "Load it anyway!" and not think about it, even in financial management firms. Ask me how I know...
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!
Possibly CT logs revealing information about domain name and IP address spaces, or other information through implementation details, that might not otherwise be public.
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?
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 got the impression you did a very good job of writing it by yourself and adding claudisms just makes it feel less trustworthy and slightly grating.
Not calling you out or anything i just take don't understand what people think they're gaining when they add a dash of claudeslop to an otherwise well written article, it confuses me. You do you though
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 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.
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.
There are a lot of CAs that are essentially grandfathered into root programs (and there’s no “one” root program, every OS and verifier gets to choose their own inclusion policies). They might need to jump through hoops to stay in any given program, but being there in the first place is not a strong indicator of quality.
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.
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?
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.
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).
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.
> 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 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.
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.
You have to make sure your VM + GPU hide or falsify all identity information. They just have to find one API or signal that you missed that reveals it.
Yes, however, this causes people who know what they do suffer because of people who don't. My question is whether this affects innovation, because the same thing at different places definitely does, and we actively fight against this exactly to help innovation.
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.
Yeah those devices also need to be “opened up” as it were. Some of them already have been. Just think about it like fermented whiskey. Leave them alone for a month or two until they run an opensource firmware you control.
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.
328 comments
[ 0.30 ms ] story [ 21.2 ms ] thread8 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.
There are two hard problems in computer science: naming things, cache invalidation, and off-by-one errors.
Also: https://martinfowler.com/bliki/TwoHardThings.html
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.
https://xkcd.com/221/
“eMudhra intermediate CA compromise” | 947 points | 19 hours ago | 408 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.
I will never in my life not look up “for of vs for in” before writing a loop in Javascript.
https://xkcd.com/221/
> 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.
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 a script zeroed out the private key, wont the public key not work anymore?
So you create more surface area for vulnerability? We might already be at or close to the sweet spot. Security is hard.
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.
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.
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.
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'd argue that you should push this into the application layer, so rather than scoping the keys to domain names you scope them to something relevant to whatever the user authentically trusts. So the user (or OS) would pass an object at runtime to indicate which peers they want the app to trust today.
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. 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.
This way your application can work over alternative transport layers: carrier pigeons, whatever, and doesn't break just because the other party has a different names 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.
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.
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.
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.
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
they violated that trust.
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 HTTP. ..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.
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!
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.
Never assume unprofitable malice for what can adequately be explained by stupidity.
Any sufficiently advanced stupidity is indistinguishable from malice.
What next, googling the public key finds a 2 year old pastebin with the private key?
Not calling you out or anything i just take don't understand what people think they're gaining when they add a dash of claudeslop to an otherwise well written article, it confuses me. You do you though
No one is going to suspect `98761316832165974216498789746` is anything other than random. But `000000000000000123` looks suspicious.
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.
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.
Why are browsers trusting CAs which issued zero certificates since their creation 1 year ago?
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.
> 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!
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.
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.
are you sure that this is not opening to more attack vector ?????
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 says QEMU, the jig is up.
See here:
https://developer.mozilla.org/en-US/docs/Web/API/GPUAdapterI...
Live demo here:
https://www.checkadevice.com/tests/gpu/ (random web site that came up in a quick search)
You have to make sure your VM + GPU hide or falsify all identity information. They just have to find one API or signal that you missed that reveals it.
Your logic only makes sense if the user is your enemy.
Just change your WiFi password, don’t give them the new one and don’t update them lol.
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.