Yeah, out of the box. CCADB was intended to be a quick corpus test before looking at subscriber certificates...
I've done a far more thorough check of all existing CCADB certificates, thankfully no more hits. Most of my time has been spent going over the basics that everyone assumed someone else had already done - a critical mistake to ever make near security.
So unless someone has significantly more computational resources or access to more cryptanalysis research the low-hanging fruit has been caught so far."
This repository was archived by the owner on Aug 19, 2026. It is now read-only.
I guess now that we've checked, nobody will ever make a mistake like this again so we don't need this anymore? :)
wildzzz 5 hours ago [-]
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.
0cf8612b2e1e 1 hours ago [-]
I am sure the NSA will keep checking on our behalf.
Aurornis 6 hours ago [-]
Archived means it’s still available but signals that it won’t be developed.
I have to be honest, that hasn't stopped me from trying!
jlmorton 10 hours ago [-]
In retrospect, having 100 trusted certificate authorities might have been excessive.
tclancy 9 hours ago [-]
In retrospect, not having a tiny competency check may have been an oversight.
8 hours ago [-]
9 hours ago [-]
Scott_Helme_ 6 hours ago [-]
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!
londons_explore 3 hours ago [-]
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.
Scott_Helme_ 3 hours ago [-]
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!
m3kw9 6 hours ago [-]
How are they trusted if they can just generate any key they like in their back room?
swores 6 hours ago [-]
"Trusted" means how people treated them, it doesn't mean the extent to which they deserved trust.
chrisjj 6 hours ago [-]
This.
Good: trustworthy
Often bad: trusted
RALaBarge 4 hours ago [-]
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.
bigfishrunning 6 hours ago [-]
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.
otabdeveloper4 9 hours ago [-]
Correct, we only need zero.
sebzim4500 8 hours ago [-]
Interesting, what would be the alternative?
I mean specifically for the use case of the browser warning the user if there is a MITM between them and e.g. their bank.
rocqua 5 hours ago [-]
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.
zaptheimpaler 1 hours ago [-]
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.
josephg 8 hours ago [-]
Make dns secure and put certs / public keys in dns. Control over dns already gives you the right to get tls certs. It should just be connected directly. We don’t need CAs.
three14 7 hours ago [-]
tptacek argues that DNSSEC is too flawed to actually do this:
He's right. DNSSEC is a mess, and we should fix that. We should fix that whether or not we delete CAs because CAs rely on DNS to verify that you own your domain. If DNS isn't secure, neither are CAs.
In the long run, fixing bugs is almost always better than working around them. DNSSEC is a bug. So are CAs. We can and should fix both.
chimeracoder 5 hours ago [-]
His argument is that DNSSEC is fundamentally broken, and you can't fix it via incremental improvements.
He is not arguing that DNS security cannot or should not be improved; in fact, he explicitly states the exact opposite.
tptacek 4 hours ago [-]
I don't have an objection to doing a different DNS security system, and in fact I like DoH a lot. You can do DoH all the way back from authority servers if you like, and that addresses domain validation without boiling the ocean with 1990s cryptography the way DNSSEC tries to do.
GoblinSlayer 5 hours ago [-]
ECDSA was added to DNSSEC 3 years before that blog post in april 2012 (rfc6605).
tptacek 4 hours ago [-]
And then for the next 10 years APNIC wrote posts about how actually using ECDSA broke resolvers.
It's going to settle into general usability at just about the time cryptographers deprecate ECC entirely!
GoblinSlayer 1 hours ago [-]
They can be deprecated for confidentiality purpose, but DNSSEC doesn't use confidentiality.
tptacek 1 hours ago [-]
You're trying to argue that DNSSEC isn't exposed to HNDL attacks, so can use signature algorithms that CRQCs break. But that's neither here nor there: the approaching cryptographic research consensus is going to deprecate all ECC (and all RSA); yes, signatures aren't the priority for immediate removal, but nobody is recommending ECC signatures. The point is all this is happening just as ECC in DNSSEC may finally be stabilizing.
ranger_danger 7 hours ago [-]
I have seen their comments across this site for a very long time. Unfortunately I do not respect or put any stock in what they say, because of how unbelievably rude and dogmatic they are, and always have been.
"As a rule, strong feelings about issues do not emerge from deep understanding."
icedchai 6 hours ago [-]
Fortunately, you can investigate this stuff for yourself and develop your own opinion. IMHO, DNSSEC doesn't actually "secure" much of anything. It can be disabled trivially by anyone operating a resolver. As I mentioned elsewhere, none of the major sites (FAANG) use it. What does that tell you?
GoblinSlayer 2 hours ago [-]
Then propose a censorship resistant protocol.
ranger_danger 5 hours ago [-]
Yes I'm not saying DNSSEC is or isn't good. I think a multi-layered approach would be best for redundancy.
tptacek 2 hours ago [-]
Wait. Hold on. It is either good or it isn't. If it's good, we should be using it (maybe in a layer cake, maybe a la carte). If it's bad, it should not be used anywhere.
shiandow 8 hours ago [-]
Making DNS secure is not trivial though. In a way that's just moving the problem.
josephg 6 hours ago [-]
A secure DNS is valuable whether or not we get rid of CAs, since CAs rely on DNS queries to verify domain ownership.
And if we have a secure DNS, then CAs are completely redundant. I'd much rather trust a handful of domain registrars than a handful of domain registrars, plus 100 random questionably competent organisations all over the world. Especially when any one of them can generate keys for every domain on the planet.
tptacek 2 hours ago [-]
"Secure" doesn't mean anything. A closer (though still imprecise) descriptor is the CIA triad --- confidentiality, integrity, and availability.
A confidential DNS has real value. Without it, ISPs actively monitor customers and sell analytics about usage upstream; there are other problems, but virtually every US user faces that one. It's hard to imagine wanting to trade confidentiality off.
A high-integrity DNS is a more dubious proposition. You'd obviously rather have integrity than not, ceteris paribus, but we have effective mitigating controls for DNS forgery, so you might imagine trading it off.
Availability also sounds like a no-brainer, until you remember that almost every other component of the networking stack also has availability issues. You might not want to trade anything at all to get a more highly-available DNS, if you're going to be just as susceptible to DOS attacks because the current DDoS meta is application-layer anyways.
There are a bunch of different approaches to securing the DNS, and they make different tradeoffs.
DoH focuses on confidentiality, and has bank-shot benefits to integrity (because it breaks forgery attacks from on-path attackers). Confidentiality is its primary purpose and it trades basically everything else off.
DNSSEC makes the opposite tradeoffs: it's exclusively for integrity, provides no confidentiality, and highly prioritizes availability (that's why it has elaborate authenticated denial systems).
Depending on what you want to achieve, "secure" DNS can make sense and actually get deployed and used, as DoH is, or it can make almost no sense and see almost no uptake.
GoblinSlayer 1 hours ago [-]
Security provided by CAs is TLS Web Server Authentication (1.3.6.1.5.5.7.3.1). CAs too are exclusively for integrity, provide no confidentiality and don't prioritize availability.
darkwater 6 hours ago [-]
It seems a nice thing to have indeed, but domain registrars have already a history to cede control and bend to $GOVERNMENT. We have countries already trying to MiTM all their citizens by mandating CAs injection in every device under their jurisdiction, what would be the defense against this threat in a world where registrars hold the keys to TLS encryption for the web on the TLDs they own as root?
I'm not that expert in this field so I really would like to learn if it's possible.
GoblinSlayer 2 hours ago [-]
Government can compel servers in its jurisdiction to use a mandated CA. DNS would nicely compartmentalize it to the zone controlled by that government as opposed to the CA system where every random eMudhra CA has infinite reach.
shiandow 4 hours ago [-]
Not that it isn't an interesting question but what's preventing them now? You can get a certificate for any domain you control. It is just really obvious if you abuse that power. Which shouldn't really change with DNSSEC I think.
vesinisa 8 hours ago [-]
Isn't this what DNSSEC solves?
SAI_Peregrinus 8 minutes ago [-]
No, DNSSEC tries to solve one part of the security of DNS (security of records between resolvers) and does nothing for the security between the user and their DNS server. And doesn't even do a good job at the bit it tries to solve.
shiandow 7 hours ago [-]
It should, though it achieves that goal by a chain of certificates not unlike CAs just tied to DNS. Like I said, it essentially just moves the problem.
Which might still be better, if only because it limits the surface area.
muvlon 8 hours ago [-]
DNSSEC deployment has been anything but trivial. This APNIC post from 2024 estimated that about 1% of DNS queries were being validated via DNSSEC: https://blog.apnic.net/2024/05/28/calling-time-on-dnssec/. That's more than 25 years after the IETF first standardized DNSSEC.
tptacek 2 hours ago [-]
I track DNSSEC adoption across the Tranco research list of top domains:
2107: The year of IPv6, DNSSEC, and The Linux Desktop.
jayd16 3 hours ago [-]
So like, the cable company now controls the certs for most consumers?
shudders
tptacek 2 hours ago [-]
Yes. This is basically the DANE pitch. Subtextually, supporters argue that two big shifts will immediately happen:
(1) We're also rearchitect the way all DNS is done so that every lookup from every phone and laptop is fully recursive, so that everyone validates DNSSEC chains instead of relying on the AD bit that cable company DPI devices switch off.
(2) People will lose all attachment to their current domain names and simply migrate to TLDs that have policies they agree with, rather than .COM and .IO, which are under the demonstrated de facto control of the NATO IC.
braiamp 8 hours ago [-]
That still requires trust stores to be distributed to the clients and some clients don't need that baggage on the dns. Also, dns is by default insecure, dnssec is a configuration nightmare
otabdeveloper4 8 hours ago [-]
> That still requires trust stores to be distributed to the clients
There's no such thing as a "trust store" in practice. To be "trusted" you just need to demonstrate you have control over a DNS TXT record, and we don't need a special "store" or intermediary for that.
Certificate authorities are an artifact of a bygone time and an entirely different model of internet infrastructure.
woodruffw 7 hours ago [-]
The trust store refers to the collection of parties that ultimately verify the signed claim of your control over a domain, which might have taken the form of a DNS TXT challenge (or any other number of challenges). You still need it, because there would otherwise be a basic circularity when determining whether to trust a connection.
(Moving the PKI into DNS does not remove it, it just moves it around.)
josephg 6 hours ago [-]
> (Moving the PKI into DNS does not remove it, it just moves it around.)
Better in DNS though. You could have certs mirror the structure of DNS. Install a single root signing key for the top level DNS registry on client devices. Then you can query that to find out the signing keys for .com, .net, .au, etc. And continue from there.
One big problem with the CA system is that any CA - even the most incompetent - can sign certificates for any domain. If trust was moved to DNS, there would only be a single organisation that could forge certificates for any given domain. Using 7 as a private key? What a joke. The CAs aren't worthy of trust.
We already have to trust the domain name registrars anyway, since CAs query them to figure out if you own a domain before signing a certificate. In total, removing CAs would not only simplify the system. But it would allow scoped signatures. And we'd end up needing to trust far fewer actors to have a secure internet.
itintheory 4 hours ago [-]
> One big problem with the CA system is that any CA - even the most incompetent - can sign certificates for any domain.
Is this not what CAA records were intended to solve? It seems like in practice they're only used by CAs to decide if they can sign a cert for a given domain, but it seems like a client could use it to determine if a server cert was from the correct CA.
parasyte 3 hours ago [-]
CAA records were never intended to be used by clients (Relying Parties), the RFC specifically prohibits them from using the CAA record to determine if the issuer was allowed to have issued the cert.
I infer from the wording around there and elsewhere in the RFC that this is mostly because someone could switch issuers but still serve valid certs from the prior issuer, and there's no way an RP would have a historical record of which CAA values were in effect when to be able to determine if the issuance was valid or not.
Scott_Helme_ 3 hours ago [-]
CAA records are only checked by the CA at the point of issuance, not by the client later. If they did, there are problems to consider:
1. A domain would have to keep the CAA records for a CA in place to keep using the certificates from that CA, but that means continuing to authorise new issuance too. Right now, I can remove the `letsencrypt.org` value to stop them from issuing new certificates for me, but I can keep using any certificates I have until they expire.
2. The client would need to have support for this new DNS RR type.
3. The client would need a secure way to query DNS, which is not widespread.
woodruffw 6 hours ago [-]
Why would I trust my domain registrar to maintain PKI? They don’t seem inherently better suited for it, and in various ways are more susceptible to meddling for e.g. ccTLDs.
I think the idea that CAs are uniquely incompetent is probably incorrect.
asksomeoneelse 8 hours ago [-]
But how do you make DNS secure without CAs?
growse 8 hours ago [-]
You just have one big one on the root.
(Half joking).
josephg 6 hours ago [-]
Better to trust 1 organisation than trust 100.
asksomeoneelse 7 hours ago [-]
Is that a reference to the Root Key of DNSSEC?
__MatrixMan__ 7 hours ago [-]
Stop validating names, start signing content.
Scan a QR code when you open the bank account, add it to the keys you trust as authorities on financial things. When your browser runs accross data tagged "financial" it checks the trusted keys in that domain and renders it only if it was signed by a key that is trusted in that domain (the domains prevent your bank from abusing that trust by causing you to see political ads or some such).
If you ever see something that you suspect is malicious, you untrust whichever key signed it and take it up with whoever asked you to trust their key. If you verify it's malicious, gossip the bad keys to your friends so they can distrust also.
tptacek 43 minutes ago [-]
You are describing key pinning. You have invented QR-code-based key pinning.
diarrhea 6 hours ago [-]
That solves integrity but not confidentiality. It does not protect against MITM.
__MatrixMan__ 3 hours ago [-]
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.
pixl97 2 hours ago [-]
>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.
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.
__MatrixMan__ 9 minutes ago [-]
> 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.
lokar 4 hours ago [-]
So, have each domain run its own root CA (scoped to the domain), and have users trust them one at a time when they have cause to interact with them?
__MatrixMan__ 3 hours ago [-]
Yes to smaller scopes, with keys passed of during interactions that organically arise, preferably face to face, but maybe not always. No to making domain names be the thing that's being trusted.
We should push this into the application layer, so rather than scoping the keys to domain names let's scope them to something relevant to whatever the user authentically trusts. Something to do with their intentions for using this app. Because most users don't even know what a CA is, but they understand that most of the time they'll need to trust somebody. So let the app decide what that's going to mean because those dynamics are always going to depend on the situation.
So the user (or OS) would pass an object at runtime to indicate which keys they want the process to trust for this session. Typically it'll be another human or a company, not a server name, but I suppose it could also be a device. Something that can guard a key pair and be identified by its ability to produce valid signatures. That way you're just not relying on globally unique human friendly names at all. Doing so puts you in a cursed corner of zooko's triangle.
Users can assign a pet name for whoever they're trusting at the time they're configuring that trust since that's the moment they're best able to scrutinize the trustworthiness of this individual or company or device. Not later on when they're installing software updates and have no context for the decisions they're making.
This way your application can work over alternative transport layers: carrier pigeons, lobbing an SD card over the border wall, whatever, and doesn't break just because the other party has a different name on the new transport. Relevant for when the internet goes down and you still want it to work with other hosts on the LAN or the local mesh or whatever.
chrisjj 6 hours ago [-]
> When your browser runs accross data tagged "financial" it checks the trusted keys
'Cos no scammer would ever be so sneaky as to leave off the tag... /s
> it up with whoever asked you to trust their key
'Cos no scammer would ever pretend to be that person... /s
__MatrixMan__ 2 hours ago [-]
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.
chrisjj 38 minutes ago [-]
Anything relying on user recognising some tag colour seems like an unsolvable UX problem to me.
lukewarm707 8 hours ago [-]
For me the complexity of anything connected to public internet is now over what I can secure.
I genuinely can't say I secured a PC, when it needs to phone home for a configuration at this point.
We are most likely over the line for needing to airgap a personal PC.
Ohentis 7 hours ago [-]
I quite like how i2p does it. Public keys are part of addresses, human readable names are user defined and shared but static.
embedding-shape 8 hours ago [-]
The first time you go to the bank, you do the "trust exchange" (maybe scanning a QR? People sure love that) that verifies future connections, similar to how you acquire digital certificates today when you deal with the government online and similar.
Edit: > Every time you access your bank on different devices normalizes it so that visiting a typo domain would show the dialog and many would just click through.
Show the dialog? What dialog? There is no dialogues here, you cannot login to the bank unless you've verified the connection. You do it with your phone, then you can propagate the trust from there to other devices if needed.
bluehatbrit 8 hours ago [-]
Not all banks have physical locations, not everyone has the ability to get to the ones which do.
You can't walk back from the existing expectation and ease of use we have today. It's just not going to happen, people will opt for the current path because it's easy and seems good enough to them.
Most normal people don't even know this whole thing is going on. They don't know the difference between http and https other than "it's secure".
If we want to improve on this, it has to come with the current level of ease of use at a minimum.
monsieurbanana 7 hours ago [-]
> If we want to improve on this, it has to come with the current level of ease of use at a minimum.
OR it has to be a situation catastrophic enough. I don't think this one is, but it's hard to be optimistic for the future
6 hours ago [-]
__MatrixMan__ 6 hours ago [-]
Presumably you had some reason to trust the bank in the first place. Maybe a recommendation from somebody you know? Get the key from them.
The current level of ease is not being achieved securely. If it's not possible to do so, we should walk it back.
pixl97 2 hours ago [-]
> Maybe a recommendation from somebody you know?
This works great for something that are obvious. "Hey, this plumber was good and cheap".
The problem is this completely and totally breaks down where things are obscure. When things turn from "reals" to "feels" the amount of manipulation a bad actor can perform is great.
chrisjj 6 hours ago [-]
> If we want to improve on this, it has to come with the current level of ease of use at a minimum.
We need to recognise that is impossible. Making getting into a bank account easier for the owner does so for everyone else too. And also makes it easier for the bank to ditch the secure fallback - a building.
And ask why vendor-indepedent trust shops aren't sprouting in every locale. Answer: same security problems.
We are well and truly doomed to living in a scammers' paradise.
venzaspa 5 hours ago [-]
But my bank has no physical buildings whatsoever?
And also, how is my bank supposed to safely generate and distribute a key that we can exchange securely if an organisations who's primary purpose to generate these keys couldn't even manage to do so.
I have plenty of other services I use too. Suddenly my phone company, doctors, supermarket has to create and distribute keys for me to go around collecting so that I can securely talk to them and we have to do this in a way that stops anyone from swapping those keys out before they get to me.
I mean the current system isn't perfect, but it's a Utopia compared to that.
chrisjj 3 hours ago [-]
Yes. As I said, we're doomed.
bee_rider 5 hours ago [-]
That could be kind of interesting.
It does seem to lean on the physical bank-front being trustworthy (no evil clerks).
If we’re meeting physically to set up connections, we could even use something like a one-time-pad, and be information-theoretically secure. How many bits does your bank really need to send you securely anyway?
whywhywhywhy 8 hours ago [-]
Every time you access your bank on different devices normalizes it so that visiting a typo domain would show the dialog and many would just click through.
u8080 6 hours ago [-]
Like...TOTP or FIDO2?
lirolero 8 hours ago [-]
[dead]
BirAdam 9 hours ago [-]
or, perhaps you need more so that one being stupid doesn't effect so much.
epanchin 8 hours ago [-]
Each CA is like a padlock locked in series with other padlocks. The weakest padlock is the only one that matters.
akerl_ 7 hours ago [-]
In a world with CT logs and CAA records, is that actually the case?
zbentley 6 hours ago [-]
Yes, because as we are seeing with this incident, plenty of things don’t check CT logs (and thus can still be hacked if CT isn’t published for bad certs), and CAA records are fundamentally advisory.
akerl_ 5 hours ago [-]
You said "yes" but then answered "no"?
Like it seems your disagreement is that you're pointing out there are systems today that trust WebPKI CAs but don't validate CT/SCTs. I'd agree that that's an issue and I want those systems to join the world where CT exists.
As I said, in a world with CAA records and CT logs, this isn't an issue. If your CA wants to be in root trust stores, you have to put your certs in CT logs. CAA records are "advisory" in the sense that we mandate that root-trusted CAs obey CAA records and that they write cert issuance to CT logs, so a trusted CA that violates CAA records has to tell on itself in a very detectable way.
Scott_Helme_ 4 hours ago [-]
I'm just not sure that I can see a world where all devices that rely on TLS/PKI are capable of CT SCT validation. Look at the issues we have around stale root stores still happening when we have validity periods of literally decades. Some of these clients out there simply won't ever be able to keep their trusted log store updated.
Similarly to vaccines, part of the magic is that you don't need "all", you just need "most".
Right now CT support is rough for things outside of browsers; it's a pretty fair bet that if you pick up a command line tool or library, it is not checking SCTs, and that makes those workflows vulnerable. If we flipped that, and the average command line tool or library did validate by default, it would dramatically alter the risk calculus for attackers.
Scott_Helme_ 4 hours ago [-]
For a scenario like this it doesn't help a given client what % of the ecosystem does SCT validation or not, all that matters is whether that client does it.
I agree that more SCT validation across the ecosystem reduces the value of a mis-issued certificate to an attacker, but a lot of value still remains.
If 90% of clients did SCT validation, an attacker can still succeed against the 10% that don't, there's no herd immunity.
lelandbatey 4 hours ago [-]
You said:
> In a world [where] CT logs and CAA records [exist]
And we are in that world. CT logs and CAA records exist. They are around. What you are implying you said is:
> In a world with CT logs and CAA records [and everyone/everything reads and validates them]
We are not in that world, and we probably won't enter that world for the next 15 to 20 years because we are also in a world where folks expect networked devices to be able to communicate (mostly) securely without constantly communicating with a centralized set of clearinghouses arbitrating "what is secure".
As we are discovering, our flawed systems may need broader rethinking, especially if we want secure communication (with all the epistemological ball of yarn that comes with it) without constant total centralization, which seems to be the approach-of-least-resistance lately.
caaqil 8 hours ago [-]
> perhaps you need more so that one being stupid doesn't effect so much.
So you create more surface area for vulnerability? We might already be at or close to the sweet spot. Security is hard.
Gabrys1 7 hours ago [-]
I would assume that the client would need to validate the certs against more than 1 trust path (for the comment to make sense)
jasonjayr 8 hours ago [-]
> It's fortunate that the steps required here aren't particularly complicated for the devices you can update, and the advice essentially boils down to 'update them'. The problem is the devices you can't update or update easily.
> Update everything that ships a CA bundle: your OS ca-certificates package, certifi, Node, Homebrew, and rebuild your container images once the base images pick up the change.
> Devices you can't update are the hard part. Routers, printers, TVs, appliances with frozen firmware will trust these certificates until expiry, which is July 2039...
Quick -- we need to MITM all the smart TVs so they can be jailbroken in one fell swoop!
__MatrixMan__ 7 hours ago [-]
Devices that are smart enough to talk to the internet but not smart enough to let the user install their own certs should not exist.
tonyhart7 6 hours ago [-]
"let the user install their own certs should not exist"
are you sure that this is not opening to more attack vector ?????
andix 2 hours ago [-]
You can even install your own certs into the golden cage (also known as iPhones).
__MatrixMan__ 2 hours ago [-]
Yes. We're giving the user the ability to protect themselves from the vendor.
Your logic only makes sense if the user is your enemy.
mitxela 2 hours ago [-]
I am the vendor and the user is my enemy. Fortunately I get to decide his capabilities and not the other way around, so I win.
JoshTriplett 28 minutes ago [-]
The device is in the user's possession, so you'll lose eventually, it's just a matter of how long it takes.
esseph 44 minutes ago [-]
Oops, claude just cracked your system!
LtWorf 6 hours ago [-]
Users aren't supposed to be considered an attack vector. I don't care what the advertisers think.
axus 6 hours ago [-]
The infected devices on the LAN are an attack vector, though.
mapontosevenths 5 hours ago [-]
If I want my IOT garbage to be infected that's between me and my local botherder.
The vendor loses the right to decide how my things are used the minute they take my money.
mitxela 2 hours ago [-]
Not in the EU. If devices you made get hacked in the EU and you have a business presence there, you're liable for the resulting damages under the Cyber Resiliency Act. If you don't notify the authorities promptly upon discovery, you might also be criminally liable.
esseph 36 minutes ago [-]
What if your company doesn't exist anymore, and you have checks billions of devices out there that won't be getting firmware updates?
antonvs 5 hours ago [-]
Users are attack vectors in one of the more commonly successful attacks: social engineering.
gus_massa 3 hours ago [-]
Like: To verify you are human, clik on the two ducks and install this new certificate.
Bonus points if it's during a fake job interview.
antonvs 2 hours ago [-]
Absolutely. "To access our secure site, install this certificate as follows..."
mitxela 2 hours ago [-]
I did a job interview in a VM once and my legitimate accounts on some platforms got banned for using them in a VM. So you can't even protect yourself.
no-name-here 45 minutes ago [-]
> my legitimate accounts on some platforms got banned for using them in a VM
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.
Y_Y 27 minutes ago [-]
Bullshit. How would a website even detect a VM?
ruszki 3 hours ago [-]
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.
tempfile 6 hours ago [-]
Which is better - two attack vectors that can be mitigated by an expert, or one attack vector that can't be mitigated by anyone?
panarky 3 hours ago [-]
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.
Scott_Helme_ 2 hours ago [-]
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.
ezoe 7 hours ago [-]
These devices are already very weak and many of them even do non-TLS updates with no signing check anyway.
If it has been so weak already, it can't be weaker.
Sayrus 7 hours ago [-]
Not always true. I have IoT devices where a valid certificate is useful because the original host doesn't exist anymore and the certificate isn't pinned.
Flashing the devices require direct UART/USB access which may involve soldering, if it even exists. This leak is gold for those because these devices will never get an updated CRL.
happyPersonR 3 hours ago [-]
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.
junon 3 hours ago [-]
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.
geeio 2 hours ago [-]
I have a terrible LG smart TV (that seems to connect to WiFi that is not mine), but I would instantly return a TV that did this.
Scott_Helme_ 6 hours ago [-]
Just imagine how much stuff you're going to be able to MiTM now!!
justincormack 8 hours ago [-]
Some of them seem to do some cert pinning
mschuster91 8 hours ago [-]
> > Devices you can't update are the hard part. Routers, printers, TVs, appliances with frozen firmware will trust these certificates until expiry, which is July 2039...
The interesting question is, how many of these devices will have the compromised CA root certificate in place?
Oh and another thing is problematic, many a Java app ships with its own keystore.jks if it needs to trust some privately hosted endpoint, and that keystore.jks may or may not contain the compromised CA root certificate... updating the OS will not catch this kind of stuff.
cromka 4 hours ago [-]
> 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.
londons_explore 3 hours ago [-]
I'm rather surprised google doesn't require cert pinning for all connections to any google server....
7 hours ago [-]
binyu 8 hours ago [-]
[dead]
irusensei 6 hours ago [-]
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?
There is an extra wardrobe."
Scott_Helme_ 6 hours ago [-]
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.
reisse 6 hours ago [-]
Yeah, it's happening in the wild already. Seen more cases like that.
cromka 6 hours ago [-]
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.
gagan2020 9 hours ago [-]
"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.
asveikau 27 minutes ago [-]
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.
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.
alphager 4 hours ago [-]
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.
Parodper 1 hours ago [-]
> 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).
Scott_Helme_ 44 minutes ago [-]
Wouldn't that be almost 2,000 root CAs?
Also if it's the same CA operating a bunch of different roots for different TLDs, they're likely to just make the same mistake that impacts them all. Sadly, I can't see anything like this working.
tptacek 2 hours ago [-]
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.
bombcar 10 hours ago [-]
Of COURSE it's easy to crack, 4 isn't even prime!
DavidSJ 9 hours ago [-]
In their defense, they were probably targeting the Mersenne prime 2^2 - 1 and just made a typo.
throw0101a 9 hours ago [-]
> 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.
zapkyeskrill 7 hours ago [-]
Two, and only two?
amoss 7 hours ago [-]
You have almost understood the joke.
floydnoel 1 hours ago [-]
two is off-by-one from three btw
motionlessveloc 7 hours ago [-]
[dead]
wolfi1 9 hours ago [-]
ok, it's joke. but for those who don't get it: elliptic curves don't need primes
joshuat 10 hours ago [-]
It’s really impressive no one caught their three previous private key values
bcvvvy 10 hours ago [-]
I suspect they did but it wasn't publicised.
chompychop 8 hours ago [-]
They should have gone with 57. Everyone knows it's prime.
bee_rider 5 hours ago [-]
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).
samatman 4 hours ago [-]
Me! I'm in!
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.
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
ohuf 5 hours ago [-]
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
Hey, that's the same combination I have on my luggage!
wowczarek 8 hours ago [-]
Good job the Earth doesn't have an air shield protected by this byte or we'd be Skroob'd.
Ambroos 6 hours ago [-]
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.
M2Ys4U 4 hours ago [-]
Either that or it's running PHP
jesuswasjew 5 hours ago [-]
I see you love technology.
chrisjj 5 hours ago [-]
You'll know this evening when it demands $10 to release your meal.
geye1234 4 hours ago [-]
For those running Ubuntu, the following page tells you what to do. It's two commands:
I will say, there’s something almost reassuring when something goes boom that badly and the story is really silly. It’s like [horrific human-caused disaster] but it’s because of a Three Stooges episode.
skinfaxi 7 hours ago [-]
The more cynical among us think that is part of it. Remember when Bush Jr. became a bumbling idiot for a few years?
supernes 9 hours ago [-]
Two more things to note about impact assessment: Flatpak uses the selected runtime's baked-in trust store (I think), so any apps may be susceptible even if you update the system package. Containers also don't inherit the host's trust store and use the one from the base image.
seanalltogether 6 hours ago [-]
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?
CSMastermind 6 hours ago [-]
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.
chrisjj 2 hours ago [-]
> 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.
nomel 4 hours ago [-]
> 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.
ooopdddddd 6 minutes ago [-]
There are several very practical reasons (and not emotional) reasons to expect that "4" is the result of bad implementation.
I can think any number of programming mistakes that will result in a supposed (pseudo-)random number generator to be be biased to very small numbers. I have made such mistakes myself.
By any reasonable estimate, the probability of randomly picking a number below 256 is MUCH smaller than the probability of someone having made a mistake.
Quinner 4 hours ago [-]
If you cherry-pick that statement in isolation you're technically correct. But in practice the whole comment you're replying to is actually correct, in this case if you saw the number four, one would be correct in concluding that's unlikely and searching other low digit numbers, the proof of that is that it happened here.
eatkd 4 hours ago [-]
They had multiple keys and 7 of the keys were numbers less than 256.
nomel 3 hours ago [-]
Yes, and that is what's statistically impossible. They said one cert.
> In this case one cert gets defeated and you go the odds of that number being that low are 2^-384.
wakamoleguy 6 hours ago [-]
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.
kstrauser 4 hours ago [-]
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.
betterunix2 5 hours ago [-]
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."
adzm 6 hours ago [-]
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.
himinlomax 6 hours ago [-]
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₂.
andix 2 hours ago [-]
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.
cududa 2 hours ago [-]
It’d be absurd to believe nobody tested these, and that no individuals involved in relevant standards bodies were aware of this weakness.
andix 2 hours ago [-]
Those 8 bit certs were out for over a year, in the public. So nobody tested them. At least no independent security researcher.
pixl97 2 hours ago [-]
We live in an absurd universe, the absurd should be expected.
floydnoel 1 hours ago [-]
"absolutely no way that there is a $100 bill on the sidewalk- if there were, somebody would have picked it up already"
Scott_Helme_ 2 hours ago [-]
If you've got the compute power, it's easy enough to have a go at it!
__MatrixMan__ 2 hours ago [-]
Is it legal? I thought the DMCA protects flimsy security of this kind by making it illegal to check if its flimsy.
andix 2 hours ago [-]
No idea what the DMCA says. It doesn't apply in most parts of the world, and also not where I live. So it's for sure legal somewhere.
1 hours ago [-]
Scott_Helme_ 1 hours ago [-]
I'm not sure what laws apply to you where you live so you'd have to check, but you could also do this on pen and paper if that helps :)
andix 1 hours ago [-]
What I've heard about the DMCA, they will even throw you in jail if you crack the calculation in your head. Without telling anyone or writing it down. ;)
1 hours ago [-]
charles_f 6 hours ago [-]
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!"
zkmon 2 hours ago [-]
>> "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.
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 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.
hnfong 8 hours ago [-]
Of the thousands of people bored with a swarm of AI agents, is it not plausible that somebody would just say "hey, let's do a vibe check to see whether any CAs are trivially crackable"?
consp 8 hours ago [-]
> and presumably nobody would try to brute-force a private key.
Why not? There are examples of RNGs providing very poor entropy which might be a reason to check it (looking at you Sony).
nmeofthestate 8 hours ago [-]
Just seems weird for anyone to focus on trying to crack private keys starting with absurd 8-bit values that "nobody would use for a private key", let alone bother to do it at all, given the search space.
consp 8 hours ago [-]
I would not expect anyone to be on the lookout continuously, but like the researcher doing a "yolo" and trying. There are enough people out there that it is likely to happen at least once in a while. Or for instance someone looking for a firmware exploit in a downstream device.
smaudet 6 hours ago [-]
And here you learn why security is often just theater (not saying a proper elliptic key is theater)...
It took less than a second to factor this key. Why not attempt, say, to factor every CA, with a budget of less than a minute each?
The reward/risk ratio is skewed so heavily in favor of trying, the only reason not to is this idea that it is "impossible".
It's clearly not, hence, the theater. Your locks don't have to work, they often only have to look like they work...
cowlevel 1 hours ago [-]
Factoring is for RSA. The best non-quantum attack against ECDSA is meet-in-the-middle brute force, with sqrt complexity. With RSA you can check if any keys in the world have any low factors and that might be interesting to do, even if you don't get any complete keys. With ECDSA the search is all or nothing and without an obvious starting point.
7 hours ago [-]
closetheloopdev 3 hours ago [-]
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.
Scott_Helme_ 3 hours ago [-]
Yeah, this would work.
closetheloopdev 3 hours ago [-]
Thank you! Working on the proxy now ...
AnkitGuptaTruth 3 hours ago [-]
The needful is complete
positive-spite 10 hours ago [-]
That's some criminal negligence right there.
8 bits is crazytalk!
joshuat 10 hours ago [-]
“4”
hey chatgbg what is a “private key”
Agentlien 9 hours ago [-]
As someone from Gothenburg, Sweden (often referred to as gbg) I shall answer:
A private key is a tiny number you don't need to share publicly because it is easy enough to guess.
Hamuko 9 hours ago [-]
Maybe they were counting on the fact that usually the right answer to “I’m thinking of a number between 1 and 10” is “7”.
bombcar 8 hours ago [-]
Isn't 4 simply 2 bits?
Silly 2-bit outfit.
Maybe it's 3 bits.
patrickthebold 8 hours ago [-]
I think the way that the bits are counted is based on the pool from which the number was randomly drawn. So it's possible they had 256 bits of entropy but got really unlucky.
thesz 5 hours ago [-]
Their other keys are also in 0..255 range. This is definitely not "really unlucky."
I guess they used (x `mod` 256) instead of (x `mod` (2^256)).
10 hours ago [-]
Qision 10 hours ago [-]
It feels like they chose the private keys by hand.
PalmPilotProMax 10 hours ago [-]
Artisanal cryptography. Hand-picked private keys salted with organically sourced nonces.
tclancy 9 hours ago [-]
Brooklyn-based. Guy in overalls and a waxed mustache hands out the bits.
bigfishrunning 6 hours ago [-]
Don't forget the leather apron, it's a messy job
donandon 10 hours ago [-]
Made with love
account42 9 hours ago [-]
Sharing is caring after all.
muvlon 9 hours ago [-]
My bet is on one of
- A sequence number being accidentally used as the private key or
- The private key being generated securely but then accidentally truncated to 8 bits (e.g. writing a single char into a zeroed buffer when you should've memcpy'd from a char*).
The sequence number idea is supported by the fact that two of the G3B private keys are consecutive numbers. I ran a quick Monte Carlo simulation and if I got it right, sampling 8 keys from [0,255] uniformly at random (as in the truncation scenario), you'd expect them to contain 2 consecutive numbers only about 18% of the time.
account42 9 hours ago [-]
All the numbers also have digits going from left to right on a keyboard. I think the manual "random" input theory is plausible.
7 hours ago [-]
muvlon 8 hours ago [-]
Oh wow, that is even more damning. Only 146 out of the possible 256 keys have this property. You only have about a 1% chance to get that 8 times in a row (A little more than 1% if sampling with replacement and a little less if sampling without. You'd expect them to at least not use the exact same key twice but at this point???).
> 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)
benmmurphy 5 hours ago [-]
`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.
walrus01 9 hours ago [-]
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.
Fabricio20 9 hours ago [-]
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)...
I made test.key4.lol if you want to quickly check if your device/browser is vulnerable still.
dlcarrier 15 hours ago [-]
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.
childintime 6 hours ago [-]
1. So there was no certification of the certifiers?
2. This is stupidity that rises to the level of being malicious. There is no excuse, this was a fraud. Their business was literally to promise security and.. make a profit. Nothing was ever delivered.
greengreengrass 6 hours ago [-]
> promise security and.. make a profit
Some would argue the inherent moral hazard makes these opposing outcomes that cannot be achieved simultaneously.
missinglugnut 4 hours ago [-]
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.
badgersnake 6 hours ago [-]
Like a web-of-trust model?
kyleomalley 7 hours ago [-]
Question: what about the other trusted roots? Has anyone tested them?
I’ve tested most of them (from historical archives) and have automated testing any new CA certificates that show up in CT.
I’m calling the check “luggage code entropy” (1 byte).
It was a mistake to trust so many root CAs and misapply the same level of trust where clearly it is impossible to independently verify and most of the accountability is smoke and mirrors. We need to be asking “why” here, the stated reason needs to be much more than “because webtrust audit” and “we recorded the entire operational process for key material handling on YouTube with this open source implementation of key ceremony tooling and have underwritten the strength of the private key with a few $mm dollars, to be paid out to the rest of the roots for the shared reputational damage to the entire ecosystem should we fuck up (intentional or otherwise).
sam1714 49 minutes ago [-]
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.
TazeTSchnitzel 10 hours ago [-]
Could HN start feeding submissions through Pangram so us human readers don't have to suffer with reading the nauseating AI-prose?
swiftcoder 9 hours ago [-]
Count yourself lucky - compared to Claude's prose, this is fairly readable.
jadamson 9 hours ago [-]
It reads fine to me. If it is AI, I'd like to know which one so I can use it too.
stratos123 9 hours ago [-]
It reads okay to me too, yet Pangram says it's mixed - the "What a private key actually is" section is AI, so is 'Why "it cannot be contained"' and some others.
TazeTSchnitzel 9 hours ago [-]
I think it's a hybrid text. The section about how elliptic curve keys work is particularly aggravating. Unfortunately it's also the only section that gave me new information.
karel-3d 8 hours ago [-]
It has parts that are human written and parts that are generated. I couldn't tell at first, but now seeing it in Pangram, it's kind of clear.
Scott_Helme_ 6 hours ago [-]
It was all written by me and then I had final pass/tweak with Claude.
queenkjuul 2 hours ago [-]
So parts were generated... Unless you're saying Claude just went "lgtm, ship it"
Scott_Helme_ 2 hours ago [-]
Fair enough, call it a mix if you like. I'm happy to stand behind every claim in my post, and if something's wrong, tell me and I'll fix it.
Kind of hard to understand how a bug would have generated a second pair of key so bad, and how would human would have ended up using them. Never attribute to malice what can be attributed to stupidity, but sometimes you wonder.
amoss 7 hours ago [-]
Given the usefulness of this to anybody who knew about it between the ceremony and now - assume malice.
dist-epoch 9 hours ago [-]
And an equal amount of stupidity in the whole ecosystem, apparently there are no "unit-tests" for trivial failure modes, like 8 bits of entropy, before adding a CA to the trusted list.
What next, googling the public key finds a 2 year old pastebin with the private key?
silvestrov 9 hours ago [-]
Even just a human glancing at the private key should do it.
Don't they even test script changes on a staging server? How could there be such a script error in production that was not caught in testing/staging?
This sounds very like a fundamental organization error, not an innocent whoopsie. It should lead to a permanent ban of the organization.
karel-3d 8 hours ago [-]
Well humans should NOT glance at private keys! That is the whole point of HSMs!
consp 8 hours ago [-]
I'm still flabergasted the HSM allowed this key to be generated. Then again, I've worked with HSMs, there are always many mistakes in the firmware, usually less severe though.
karel-3d 8 hours ago [-]
It seems there was some issue with the ceremony with some wrapping/unwrapping scripts.
They explicitly said they wanted to export the keys from the HSM; the keys were intended for USA/Europe (for sovereignty reasons) but were never actually used.
It seems the HSM itself worked, their ceremony around wrapping/unwrapping didn't.
consp 7 hours ago [-]
Makes more sense.
I'm sure the Utimaco's used (haven't worked with one) also allow all slots to contain the same name or keys with the same name and the device always selecting the first one if you only provide the name and not the slot ID or token identifier. Don't ask how I found out the hard way.
karel-3d 7 hours ago [-]
Yes there was something about key names in the write-up (which I cannot find now)
But eMudhra wanted to (was required to) export the keys.
So using an HSM in the first place is a security theater. Or that this HSM isn't really an HSM since it allows for export of the private key.
The trusted enclave in a MacBook is more secure than this HSM.
karel-3d 6 hours ago [-]
There is something called "wrapping/unwrapping" - you encrypt the key, move it to the other HSM, and it unwraps it. So what moves around is encrypted. I don't know enough about HSMs to tell you if it's done using symetric or asymetric crypto, but no the key should not move around in the plaintext.
The write-up from eMudhra mentions something about wrapping/unwrapping ceremony failing.
xvector 6 hours ago [-]
Most HSMs used by CAs are pretty trash tbh.
sobkas 9 hours ago [-]
Any sufficiently advanced malice is indistinguishable from stupidity.
RetroTechie 7 hours ago [-]
The reverse is also true:
Any sufficiently advanced stupidity is indistinguishable from malice.
SAI_Peregrinus 7 hours ago [-]
Never assume stupidity for what can adequately be explained by profitable malice.
Never assume unprofitable malice for what can adequately be explained by stupidity.
throwitaway222 4 hours ago [-]
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.
zkmon 2 hours ago [-]
Anything to update/check for Macs running on various versions of the OS?
Scott_Helme_ 2 hours ago [-]
Apple has blocked the intermediates, so updating is good enough to resolve it for you.
jesuswasjew 6 hours ago [-]
This does not look like blunder; more like espionage. The bigger guys are throwing emudra under the bus.
bstsb 6 hours ago [-]
“espionage” would involve a private key shared with the three-letter agencies, not a key anyone could crack in seconds
jesuswasjew 5 hours ago [-]
anyone = themselves. The key ceremony is supposed to be nuke launch level secure. That 4 pass many eyes.
Ohentis 2 hours ago [-]
I somewhat doubt it. Having many people, even at your own company, know your private key seems like a problem of it's own. In fact it's likely to me that no human has ever seen it until now.
russfink 5 hours ago [-]
> One of eMudhra's certificate authority private keys is the number 4.
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.
sethhochberg 33 minutes ago [-]
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.
sashank_1509 19 minutes ago [-]
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?
sethhochberg 2 minutes ago [-]
Generally yes - a compromised CA can be used to issue certificates for any domain, which is why when a CA is compromised the first step is usually for browser vendors, OS vendors, etc to immediately remove the compromised CA from their trust lists.
This is the compromise. In exchange for having the ability to easily establish an encrypted connection to pretty much any public web service, the tradeoff is that the entire public internet's encryption is only as good as the operations of the weakest of the big public certificate authorities.
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).
buzer 3 hours ago [-]
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.
eob 7 hours ago [-]
With the speed of vibe coding.. I'd expect the "Reverse Engineer Anything" folks to come out with a "Man in the Middle Anything" app by lunch
eviks 8 hours ago [-]
> recovered all of them from their public certificates on my laptop just now, and it took less than a second.
Why wasn't this second spend by the parties accepting those certificates as valid before they were accepted?
Scott_Helme_ 4 hours ago [-]
It's a valid question at this point.
megous 6 hours ago [-]
Well, so what now? It's not like I have these in my system CA store, they're just intermediaries cross-signed by sectigo.
akdev1l 6 hours ago [-]
You can add the intermediate CA to your block list, presumably the distros will do this
megous 5 hours ago [-]
Looks like archlinux already did. After update my fake st*pe.com cert no longer verifies. Ufff.
Scott_Helme_ 4 hours ago [-]
The problem now becomes all of the things that can't be so easily updated.
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".
dbcooper 9 hours ago [-]
All the numbers were under 384. Surely they couldn't have ...
MrDOS 9 hours ago [-]
All the numbers were under 256. Surely they did.
yoyohello13 5 hours ago [-]
I love how this article explains multiplication... very carefully.
mitxela 1 hours ago [-]
From the author of "Passkeys are not a trap", and written by Claude from the looks of it...
Scott_Helme_ 1 hours ago [-]
Hey what's wrong with Passkeys?!
unsupp0rted 17 hours ago [-]
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
MiroslavPokorny 16 hours ago [-]
This wasnt malice its was laziness.
They literally were too lazy to type more than just a single '4'.
unsupp0rted 14 hours ago [-]
Either that or they intentionally wanted to create a publicly-accessible backdoor, with plausible deniability of laziness
13 hours ago [-]
bandrami 7 hours ago [-]
Shakti de. This should be firm-ending for them but I fear it won't be.
I think this might be proprietary source code, did you get permission to share this?..
koolba 9 hours ago [-]
What the chances there’s another CA key out there with something like unix time as the key?
ls65536 7 hours ago [-]
Another place to search for private key candidates would be the outputs of various common PRNGs when they have been seeded with a timestamp (for all timestamps in, say, the past 20 years).
These would look like nice random values (unlike the ones that were recently compromised), but they would be trivial to generate by anyone who knows the initial inputs (PRNG algorithm, seed, maybe starting byte position, etc.).
> 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?
skywhopper 9 hours ago [-]
These are intermediate roots, signed by trusted root certs, so the trust from your OS or browser is implicit to the roots it trusts.
akino_germany 8 hours ago [-]
Yes, but there was no TLS cert issued that had these intermediate certs in its chain of trust at all anywhere. So why are they a CA if they don't issue any certs?
Uvix 7 hours ago [-]
Their other intermediates have issued certs.
9 hours ago [-]
jesuswasjew 6 hours ago [-]
My izzat is down right now.
sylware 8 hours ago [-]
The CA concept itself is flawed, unless normal users were able to cherry pick the CA they do trust, dream. And even with that, they must keep in mind that many authorities and/or mafias have very probably rogue certificates for browser invisible man-in-the-middle.
Scott_Helme_ 6 hours ago [-]
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?
gquere 7 hours ago [-]
Doesn't ACME+CT solve this threat?
9 hours ago [-]
AlexITC 8 hours ago [-]
Another very unfortunate even next to the php, fun times we are living in.
naabozaurus 10 hours ago [-]
hey, at least it was easy to remember...
Scott_Helme_ 6 hours ago [-]
Can't lose your key if it's easy to remember!
latencyharbor 3 hours ago [-]
[flagged]
soloviber 4 hours ago [-]
[flagged]
9 hours ago [-]
10 hours ago [-]
freebsd_lovefes 6 hours ago [-]
[dead]
m3kw9 6 hours ago [-]
This has to be a backdoor planted by hackers, mess with the key gen, say is all good. Must be known since issuance.
sscaryterry 9 hours ago [-]
I wouldn't be surprised if we learn in the near future, that this was deliberate.
edent 9 hours ago [-]
I'm not so sure. If you wanted to be deliberate, you'd choose a plausible value that you could control.
No one is going to suspect `98761316832165974216498789746` is anything other than random. But `000000000000000123` looks suspicious.
K0balt 7 hours ago [-]
But that would be obviously intentional. Much more plausible deniability with 0x4.
sscaryterry 9 hours ago [-]
Why are many of them, suspicious?
kenniskrag 8 hours ago [-]
The probability of getting a 0 is the same for every digit. However, in my opinion, the probability of getting a number that starts with two zeros is 1/10 * 1/10, and the probability of getting a number that starts with the same two digits is 10 * 1/10 * 1/10.
But the probability to receive one number or the other are the same.
matsemann 8 hours ago [-]
By random chance you probably wouldn't get that many zeros. Of course, one could say it's just as random as any other string, but..
sscaryterry 8 hours ago [-]
Not a mathematician, but I'm sure the probability of them all being below 384 is going to be in the order of 0.000000001% if not less :)
betterunix2 5 hours ago [-]
Sure, if they were actually sampling 384 bits. Sounds like they sampled a lot less than that; maybe someone though "384 bits" meant "in the range [0, 383]" or whatever.
kenniskrag 8 hours ago [-]
10 times the amount of digits is the possible number space.
smaller than 384 means 384 numbers (including 0) divided by the amount of possible numbers (see above) imho
SAI_Peregrinus 7 hours ago [-]
It's a 384-bit curve, so between 0 and 2^384 which has about 115 decimal digits.
hannob 9 hours ago [-]
Makes no sense.
If it was deliberate, one would use keys that only the person abusing it has. Not keys everyone can guess if they get a hint.
bombcar 8 hours ago [-]
Deliberate deniability - if you leak a real key, it's pretty obvious you leaked a real key.
Here, you didn't leak anything, you just fucked up.
yoavm 9 hours ago [-]
Why would it be?
sscaryterry 9 hours ago [-]
Do I honestly need to enumerate what you can do if you have the keys for a CA?
swiftcoder 9 hours ago [-]
Yeah, but if you are the one issuing the CA's private key, you already, by definition, have the keys to that CA. You don't need to make stupid keys in that scenario
sscaryterry 8 hours ago [-]
In case it wasn't obvious. The NSA and many other organisation would find this extremely useful.
yoavm 8 hours ago [-]
But it doesn't make sense. Sure they'd find it extremely useful to have the key, but it doesn't need to be a weak key for it to be useful. If anything, it makes it less useful to them.
If I'm going to ask you or force you to share your password with me, there's no reason I'd ask you to set the password to 4. We might as well agree that the password would be D#!(s9fj0jalk!4af095SF42 , and it's much more likely our collaboration will continue working for years.
"Never attribute to malice that which is adequately explained by stupidity"
skinfaxi 7 hours ago [-]
A weak key means use is unattributable.
NetMageSCW 4 hours ago [-]
A secret strong key is also unattributable.
skywhopper 9 hours ago [-]
Sounds more like extremely sloppy procedures. Which depressingly I doubt are unusual among CAs.
sscaryterry 8 hours ago [-]
As far as I know, to become a CA, with the requirements and ceremonies involved, this type of mistake must never happen. Assuming malice instead of ignorance is reasonable here. The entire premise of a CA, is trust.
woodruffw 7 hours ago [-]
There are a lot of CAs that are essentially grandfathered into root programs (and there’s no “one” root program, every OS and verifier gets to choose their own inclusion policies). They might need to jump through hoops to stay in any given program, but being there in the first place is not a strong indicator of quality.
chrisjj 2 hours ago [-]
> The entire premise of a CA, is trust.
No need for trustworthiness, then. /s
betterunix2 5 hours ago [-]
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.
Rendered at 19:36:57 GMT+0000 (Coordinated Universal Time) with Vercel.
"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...
https://en.wikipedia.org/wiki/Signed_zero
This repository was archived by the owner on Aug 19, 2026. It is now read-only.
I guess now that we've checked, nobody will ever make a mistake like this again so we don't need this anymore? :)
The one thing I don't like about archive is the inability to add new issues. If I encounter a new issue, I don't necessarily want to fork it and track the new issue myself. I don't want to take responsibility for the code, I just want to let people know so someone else can fix it if they care.
Last commit was 2 years ago anyway.
https://github.com/google/paranoid_crypto/blob/main/paranoid...
If you're talking about root certs then it's almost 350 currently trusted by at least one major operator.
If you include intermediates, you're talking more than 3,600!
They instead place the burden on individual webmasters again to actually verify that nobody has been falsely issuing for their domains. There are also some new vulnerabilities about CT logs who might be malicious.
Do you have any info on the malicious CT logs? I'd be interested to read something on that!
Good: trustworthy Often bad: trusted
Mozilla et al. could claim trust for Microsoft and then MS would be an intermediary for Mozilla. There is a long history of sketchy intermediaries like GoDaddy and others that root certificate providers like Mozilla would block at times due to abuse.
This leads to users, usually ones that are not that technically savvy, seeing 'insecure' warnings on a page that actually offers 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.
they violated that trust.
I mean specifically for the use case of the browser warning the user if there is a MITM between them and e.g. their bank.
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.
https://sockpuppet.org/blog/2015/01/15/against-dnssec/
In the long run, fixing bugs is almost always better than working around them. DNSSEC is a bug. So are CAs. We can and should fix both.
He is not arguing that DNS security cannot or should not be improved; in fact, he explicitly states the exact opposite.
It's going to settle into general usability at just about the time cryptographers deprecate ECC entirely!
"As a rule, strong feelings about issues do not emerge from deep understanding."
And if we have a secure DNS, then CAs are completely redundant. I'd much rather trust a handful of domain registrars than a handful of domain registrars, plus 100 random questionably competent organisations all over the world. Especially when any one of them can generate keys for every domain on the planet.
A confidential DNS has real value. Without it, ISPs actively monitor customers and sell analytics about usage upstream; there are other problems, but virtually every US user faces that one. It's hard to imagine wanting to trade confidentiality off.
A high-integrity DNS is a more dubious proposition. You'd obviously rather have integrity than not, ceteris paribus, but we have effective mitigating controls for DNS forgery, so you might imagine trading it off.
Availability also sounds like a no-brainer, until you remember that almost every other component of the networking stack also has availability issues. You might not want to trade anything at all to get a more highly-available DNS, if you're going to be just as susceptible to DOS attacks because the current DDoS meta is application-layer anyways.
There are a bunch of different approaches to securing the DNS, and they make different tradeoffs.
DoH focuses on confidentiality, and has bank-shot benefits to integrity (because it breaks forgery attacks from on-path attackers). Confidentiality is its primary purpose and it trades basically everything else off.
DNSSEC makes the opposite tradeoffs: it's exclusively for integrity, provides no confidentiality, and highly prioritizes availability (that's why it has elaborate authenticated denial systems).
Depending on what you want to achieve, "secure" DNS can make sense and actually get deployed and used, as DoH is, or it can make almost no sense and see almost no uptake.
Which might still be better, if only because it limits the surface area.
https://dnssecmenot.fly.dev/
shudders
(1) We're also rearchitect the way all DNS is done so that every lookup from every phone and laptop is fully recursive, so that everyone validates DNSSEC chains instead of relying on the AD bit that cable company DPI devices switch off.
(2) People will lose all attachment to their current domain names and simply migrate to TLDs that have policies they agree with, rather than .COM and .IO, which are under the demonstrated de facto control of the NATO IC.
There's no such thing as a "trust store" in practice. To be "trusted" you just need to demonstrate you have control over a DNS TXT record, and we don't need a special "store" or intermediary for that.
Certificate authorities are an artifact of a bygone time and an entirely different model of internet infrastructure.
(Moving the PKI into DNS does not remove it, it just moves it around.)
Better in DNS though. You could have certs mirror the structure of DNS. Install a single root signing key for the top level DNS registry on client devices. Then you can query that to find out the signing keys for .com, .net, .au, etc. And continue from there.
One big problem with the CA system is that any CA - even the most incompetent - can sign certificates for any domain. If trust was moved to DNS, there would only be a single organisation that could forge certificates for any given domain. Using 7 as a private key? What a joke. The CAs aren't worthy of trust.
We already have to trust the domain name registrars anyway, since CAs query them to figure out if you own a domain before signing a certificate. In total, removing CAs would not only simplify the system. But it would allow scoped signatures. And we'd end up needing to trust far fewer actors to have a secure internet.
Is this not what CAA records were intended to solve? It seems like in practice they're only used by CAs to decide if they can sign a cert for a given domain, but it seems like a client could use it to determine if a server cert was from the correct CA.
I infer from the wording around there and elsewhere in the RFC that this is mostly because someone could switch issuers but still serve valid certs from the prior issuer, and there's no way an RP would have a historical record of which CAA values were in effect when to be able to determine if the issuance was valid or not.
1. A domain would have to keep the CAA records for a CA in place to keep using the certificates from that CA, but that means continuing to authorise new issuance too. Right now, I can remove the `letsencrypt.org` value to stop them from issuing new certificates for me, but I can keep using any certificates I have until they expire.
2. The client would need to have support for this new DNS RR type.
3. The client would need a secure way to query DNS, which is not widespread.
I think the idea that CAs are uniquely incompetent is probably incorrect.
(Half joking).
Scan a QR code when you open the bank account, add it to the keys you trust as authorities on financial things. When your browser runs accross data tagged "financial" it checks the trusted keys in that domain and renders it only if it was signed by a key that is trusted in that domain (the domains prevent your bank from abusing that trust by causing you to see political ads or some such).
If you ever see something that you suspect is malicious, you untrust whichever key signed it and take it up with whoever asked you to trust their key. If you verify it's malicious, gossip the bad keys to your friends so they can distrust also.
If confidentiality is required, well you already have a public key that you're using to verify content, then the content can say: "reach us at 196.7.3.45" and then you encrypt communications to that address with the same public key you use for validating content.
Or maybe they'll specify, in the content, that you should use a different key for that, but either way the chain of trust is preserved.
This would of course all be protocol level stuff, handled by the browser, not a human. They just have to maintain a list of keys they trust.
Um, I don't think you understand this problem near as good as you think you do?
>A man in the middle can pass the content along or they can refuse to do so but they can't forge a signature.
So where do you get this signature exactly so they don't MITM you the first time?
> well you already have a public key that you're using to verify content,
Who what where when why? Where did I get this public key? Who provided it? Is this my public key or their public key? How do I trust it?
>They just have to maintain a list of keys they trust.
So you've solved exactly nothing.
That's always going to depend on why you're trusting them in the first place. If somebody handed you a business card the key should be on the card. If it was a recommendation from a friend you should use whatever key they use.
If you're expecting to just type random IP addresses into your browser until you hit something and then be told that you should trust what you see... Well that's not in the cards because you shouldn't trust what you see in that scenario.
We already don't type in URL's, we send links to each other. It really wouldn't be so difficult to change the UX so that when we delegate trust in that way it's public keys that are being trafficked instead.
> So you've solved exactly nothing.
Removing untrustworthy third parties and the need to revoke trust in them on the user's behalf is the solution. Users don't know what a CA is or how they should evaluate its trustworthiness. We need a system where they're instead evaluating the trustworthiness of things they understand, like other people.
We should push this into the application layer, so rather than scoping the keys to domain names let's scope them to something relevant to whatever the user authentically trusts. Something to do with their intentions for using this app. Because most users don't even know what a CA is, but they understand that most of the time they'll need to trust somebody. So let the app decide what that's going to mean because those dynamics are always going to depend on the situation.
So the user (or OS) would pass an object at runtime to indicate which keys they want the process to trust for this session. Typically it'll be another human or a company, not a server name, but I suppose it could also be a device. Something that can guard a key pair and be identified by its ability to produce valid signatures. That way you're just not relying on globally unique human friendly names at all. Doing so puts you in a cursed corner of zooko's triangle.
Users can assign a pet name for whoever they're trusting at the time they're configuring that trust since that's the moment they're best able to scrutinize the trustworthiness of this individual or company or device. Not later on when they're installing software updates and have no context for the decisions they're making.
This way your application can work over alternative transport layers: carrier pigeons, lobbing an SD card over the border wall, whatever, and doesn't break just because the other party has a different name on the new transport. Relevant for when the internet goes down and you still want it to work with other hosts on the LAN or the local mesh or whatever.
'Cos no scammer would ever be so sneaky as to leave off the tag... /s
> it up with whoever asked you to trust their key
'Cos no scammer would ever pretend to be that person... /s
As for tagging... We could use something like color to indicate domain. So if your well trusted plumber is giving financial advice maybe it shows up, but not in the "financial" color? Idk it seems like a solvable UX problem.
I genuinely can't say I secured a PC, when it needs to phone home for a configuration at this point.
We are most likely over the line for needing to airgap a personal PC.
Edit: > Every time you access your bank on different devices normalizes it so that visiting a typo domain would show the dialog and many would just click through.
Show the dialog? What dialog? There is no dialogues here, you cannot login to the bank unless you've verified the connection. You do it with your phone, then you can propagate the trust from there to other devices if needed.
You can't walk back from the existing expectation and ease of use we have today. It's just not going to happen, people will opt for the current path because it's easy and seems good enough to them.
Most normal people don't even know this whole thing is going on. They don't know the difference between http and https other than "it's secure".
If we want to improve on this, it has to come with the current level of ease of use at a minimum.
OR it has to be a situation catastrophic enough. I don't think this one is, but it's hard to be optimistic for the future
The current level of ease is not being achieved securely. If it's not possible to do so, we should walk it back.
This works great for something that are obvious. "Hey, this plumber was good and cheap".
The problem is this completely and totally breaks down where things are obscure. When things turn from "reals" to "feels" the amount of manipulation a bad actor can perform is great.
We need to recognise that is impossible. Making getting into a bank account easier for the owner does so for everyone else too. And also makes it easier for the bank to ditch the secure fallback - a building.
And ask why vendor-indepedent trust shops aren't sprouting in every locale. Answer: same security problems.
We are well and truly doomed to living in a scammers' paradise.
And also, how is my bank supposed to safely generate and distribute a key that we can exchange securely if an organisations who's primary purpose to generate these keys couldn't even manage to do so.
I have plenty of other services I use too. Suddenly my phone company, doctors, supermarket has to create and distribute keys for me to go around collecting so that I can securely talk to them and we have to do this in a way that stops anyone from swapping those keys out before they get to me.
I mean the current system isn't perfect, but it's a Utopia compared to that.
It does seem to lean on the physical bank-front being trustworthy (no evil clerks).
If we’re meeting physically to set up connections, we could even use something like a one-time-pad, and be information-theoretically secure. How many bits does your bank really need to send you securely anyway?
Like it seems your disagreement is that you're pointing out there are systems today that trust WebPKI CAs but don't validate CT/SCTs. I'd agree that that's an issue and I want those systems to join the world where CT exists.
As I said, in a world with CAA records and CT logs, this isn't an issue. If your CA wants to be in root trust stores, you have to put your certs in CT logs. CAA records are "advisory" in the sense that we mandate that root-trusted CAs obey CAA records and that they write cert issuance to CT logs, so a trusted CA that violates CAA records has to tell on itself in a very detectable way.
Refs: Part 1: https://scotthelme.co.uk/impending-doom-root-ca-expiring-leg... Part 2: https://scotthelme.co.uk/complexities-chain-building-ca-infr... Part 3: https://scotthelme.co.uk/cross-signing-alternate-trust-paths... Part 4: https://scotthelme.co.uk/building-certificate-chains/
There's also the Let's Encrypt root migration that was postponed due to legacy devices: https://scotthelme.co.uk/lets-encrypt-postpone-isrg-root-tra...
Right now CT support is rough for things outside of browsers; it's a pretty fair bet that if you pick up a command line tool or library, it is not checking SCTs, and that makes those workflows vulnerable. If we flipped that, and the average command line tool or library did validate by default, it would dramatically alter the risk calculus for attackers.
I agree that more SCT validation across the ecosystem reduces the value of a mis-issued certificate to an attacker, but a lot of value still remains.
If 90% of clients did SCT validation, an attacker can still succeed against the 10% that don't, there's no herd immunity.
> In a world [where] CT logs and CAA records [exist]
And we are in that world. CT logs and CAA records exist. They are around. What you are implying you said is:
> In a world with CT logs and CAA records [and everyone/everything reads and validates them]
We are not in that world, and we probably won't enter that world for the next 15 to 20 years because we are also in a world where folks expect networked devices to be able to communicate (mostly) securely without constantly communicating with a centralized set of clearinghouses arbitrating "what is secure".
As we are discovering, our flawed systems may need broader rethinking, especially if we want secure communication (with all the epistemological ball of yarn that comes with it) without constant total centralization, which seems to be the approach-of-least-resistance lately.
So you create more surface area for vulnerability? We might already be at or close to the sweet spot. Security is hard.
> Update everything that ships a CA bundle: your OS ca-certificates package, certifi, Node, Homebrew, and rebuild your container images once the base images pick up the change.
> Devices you can't update are the hard part. Routers, printers, TVs, appliances with frozen firmware will trust these certificates until expiry, which is July 2039...
Quick -- we need to MITM all the smart TVs so they can be jailbroken in one fell swoop!
are you sure that this is not opening to more attack vector ?????
Your logic only makes sense if the user is your enemy.
The vendor loses the right to decide how my things are used the minute they take my money.
Bonus points if it's during a fake job interview.
Which legitimate accounts get banned for use in a VM?
That seems like an incredibly important thing I should know as I use legitimate accounts in VMs.
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.
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.
Just change your WiFi password, don’t give them the new one and don’t update them lol.
The interesting question is, how many of these devices will have the compromised CA root certificate in place?
Oh and another thing is problematic, many a Java app ships with its own keystore.jks if it needs to trust some privately hosted endpoint, and that keystore.jks may or may not contain the compromised CA root certificate... updating the OS will not catch this kind of stuff.
I have two Google devices at home and both are compromised still. If Google can't handle pushing out a quick cert chain update, then I truly doubt other manufacturers can.
EDIT: seems its already happening? https://x.com/otomir23/status/2112697830687047918
At last, russians got better at installing wiretaps. Reminds me of the old joke that goes "How do you know there is a soviet made bug installed in your home?
There is an extra wardrobe."
EDIT: just whipped up a quick hacking session with DeepSeek and, indeed, Google hasn't updated the cert chain yet on these devices, I am sniffing everything with MITM! Let's see if I can put that to use and gain root. At the very least, a mock endpoint server is possible now for use with Home Assistant.
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.
* 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.
“eMudhra intermediate CA compromise” | 947 points | 19 hours ago | 408 comments
Previously: eMudhra intermediate CA compromise - https://news.ycombinator.com/item?id=50166579 - Oct 2026 (458 comments)
Meanwhile there are two less invasive changes that really ought to happen:
1. A clean way for things like curl and Python to start checking CT logs like Chrome does.
2. Name constraints. It’s long past time for the CAs of the world to have name constraints enforced. A CA that is not appropriate to use for .com should not work for .com. A CA that is not appropriate to use for .ae should not work for .ae. And the CA/B Forum should should requiring that all newly approved roots and all newly signed intermediates have appropriate name constraints.
2. I don't think such constraints would really work. My company might have 4 domains on different TLDs and then end up needing to use 4 different CAs. Geography doesn't really apply on the Internet.
Your CA would have a root cert per TLD. Alternatively, we get rid of non-cc TLD (and leave ccTLD only for truly geography-bound organizations, like governments).
Also if it's the same CA operating a bunch of different roots for different TLDs, they're likely to just make the same mistake that impacts them all. Sadly, I can't see anything like this working.
This is a simple point but there's something subtler underneath it. Strict name constraints are an obvious seeming improvement to the WebPKI. I like them too. but eMudhra isn't just an Indian sovereign CA; it's an important global commercial vendor. On the other thread about this incident, 'agwa pointed out that an eMudhra subsidiary does a lot of the certificates for US universities.
You're still going to end up with the same concentrations of risk, because large CAs are going to want to issue in the most popular domains.
Don't get me wrong, anything that ratchets up the difficulty of running a CA (without unduly burdening LetsEncrypt) is a positive as far as I'm concerned. I'm just saying these are hard problems.
There are two hard problems in computer science: naming things, cache invalidation, and off-by-one errors.
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.
https://xkcd.com/221/
https://ubuntu.com/blog/emudhra-ca-compromise-fixes-availabl...
In this case one cert gets defeated and you go the odds of that number being that low are 2^-384. Essentially impossible if it were randomly selected. It's much more likely you didn't choose that at random so I start guessing a bunch of other low numbers for your other certificates and find them quickly.
I have an insanely unlikely unique car licence plate number to sell you.
You would say the same of any seed I gave you. You've just artificially assigned this number with some sort of emotional importance.
I can think any number of programming mistakes that will result in a supposed (pseudo-)random number generator to be be biased to very small numbers. I have made such mistakes myself.
By any reasonable estimate, the probability of randomly picking a number below 256 is MUCH smaller than the probability of someone having made a mistake.
> In this case one cert gets defeated and you go the odds of that number being that low are 2^-384.
In short, raising the floor doesn’t really hurt the search space meaningfully.
In theory, all values would be equally random. In practice, some results are exceedingly more likely to occur when something's wrong with the algorithm.
While any given outcome of flipping a coin randomly N times is equally likely, if that series looks like [heads, heads, heads, heads, ...], then there's probably something other than pure random affecting the output.
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."
That said, a sanity check on the value somewhere in the code would indeed have prevented this.
the Audit part is scary. The same audit process might have cleared many other stuff.
https://www.einpresswire.com/article/951151580/emudhra-state...
https://xkcd.com/221
Since there's nothing to indicate that the private key was all zeroes and one non-zero lsbyte, and presumably nobody would try to brute-force a private key.
The two cases are very similar. The only difference is that the weak randomness was harmless in the earlier story, and here it’s devastating.
Why not? There are examples of RNGs providing very poor entropy which might be a reason to check it (looking at you Sony).
It took less than a second to factor this key. Why not attempt, say, to factor every CA, with a budget of less than a minute each?
The reward/risk ratio is skewed so heavily in favor of trying, the only reason not to is this idea that it is "impossible".
It's clearly not, hence, the theater. Your locks don't have to work, they often only have to look like they work...
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.
8 bits is crazytalk!
hey chatgbg what is a “private key”
A private key is a tiny number you don't need to share publicly because it is easy enough to guess.
Silly 2-bit outfit.
Maybe it's 3 bits.
I guess they used (x `mod` 256) instead of (x `mod` (2^256)).
- A sequence number being accidentally used as the private key or
- The private key being generated securely but then accidentally truncated to 8 bits (e.g. writing a single char into a zeroed buffer when you should've memcpy'd from a char*).
The sequence number idea is supported by the fact that two of the G3B private keys are consecutive numbers. I ran a quick Monte Carlo simulation and if I got it right, sampling 8 keys from [0,255] uniformly at random (as in the truncation scenario), you'd expect them to contain 2 consecutive numbers only about 18% of the time.
> We have done some preliminary assessment, there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)
that sounds like the HSM is capable of generating keys in a range that is smaller than [1..group_order). such a feature makes no sense at all. or is this some kind of weird thing where people want to generate weak keys for 'testing' and HSM vendors have added such a strange feature. its actually satisfying to see someone get burned by this because such a feature should never exist and this is the reason why. if the HSM can generate keys in a smaller range (especially some arbitrary small range) then you are putting a lot of trust in the operators of the HSM. hopefully there are good audit logs and people actually check the audit logs every time keys are generated to make sure the keys being generated aren't from a special range.
https://xkcd.com/221/
2. This is stupidity that rises to the level of being malicious. There is no excuse, this was a fraud. Their business was literally to promise security and.. make a profit. Nothing was ever delivered.
Some would argue the inherent moral hazard makes these opposing outcomes that cannot be achieved simultaneously.
Moral hazard describes situations where an entity is incentivized to take undue risk. With an upside of saving a single Indian endineers salary and a downside of destroying the entire company, it's safe to say the market wasn't incentivizing this. They were just stupid.
I’ve tested most of them (from historical archives) and have automated testing any new CA certificates that show up in CT.
I’m calling the check “luggage code entropy” (1 byte).
It was a mistake to trust so many root CAs and misapply the same level of trust where clearly it is impossible to independently verify and most of the accountability is smoke and mirrors. We need to be asking “why” here, the stated reason needs to be much more than “because webtrust audit” and “we recorded the entire operational process for key material handling on YouTube with this open source implementation of key ceremony tooling and have underwritten the strength of the private key with a few $mm dollars, to be paid out to the rest of the roots for the shared reputational damage to the entire ecosystem should we fuck up (intentional or otherwise).
Is it possible to convince the EU to say that, no, each one of your 27 member states isn't allowed to have a PKI? I don't think so.
Kind of hard to understand how a bug would have generated a second pair of key so bad, and how would human would have ended up using them. Never attribute to malice what can be attributed to stupidity, but sometimes you wonder.
What next, googling the public key finds a 2 year old pastebin with the private key?
Don't they even test script changes on a staging server? How could there be such a script error in production that was not caught in testing/staging?
This sounds very like a fundamental organization error, not an innocent whoopsie. It should lead to a permanent ban of the organization.
They explicitly said they wanted to export the keys from the HSM; the keys were intended for USA/Europe (for sovereignty reasons) but were never actually used.
It seems the HSM itself worked, their ceremony around wrapping/unwrapping didn't.
I'm sure the Utimaco's used (haven't worked with one) also allow all slots to contain the same name or keys with the same name and the device always selecting the first one if you only provide the name and not the slot ID or token identifier. Don't ask how I found out the hard way.
oh here
https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c11
So using an HSM in the first place is a security theater. Or that this HSM isn't really an HSM since it allows for export of the private key.
The trusted enclave in a MacBook is more secure than this HSM.
The write-up from eMudhra mentions something about wrapping/unwrapping ceremony failing.
Any sufficiently advanced stupidity is indistinguishable from malice.
Never assume unprofitable malice for what can adequately be explained by stupidity.
https://imgs.xkcd.com/comics/random_number.png
Here’s what I understand, every website sends some data encrypted by some key issued by CA and then the browser decrypts it first and then decrypts something in that message, to verify that Google.com, is google.com. I still don’t get why CA’s even exist, not sure what they are solving and how they’re doing it.
The first time you connect to google.com in your browser and get the google.com certificate, your web browser has to decide whether or not to trust that cert. It would be very complicated if every website on the internet had to prove its identity via some sort of out of band process, so web browsers, operating systems, etc all ship with a collection of trusted, institutionally-important certificates which are allowed to vouch for other certificates that aren't yet known to the browser, OS, etc.
Your browser (or whatever HTTPS client) basically says "I've never seen this certificate before, but Lets Encrypt (or Digicert or whoever) says they trust it and we trust Lets Encrypt, so we can treat it as trusted". You as a user are trusting that whatever verification/validation process the CA does is at least good enough to ensure that the owner of the domain is the entity giving you a certificate for that domain.
This is obviously not a perfect system. These CAs can be compromised and break the trust, and they have various levels of validation of the people and companies who come to them and ask to be included in their vouching network, etc. But its a compromise to make sure that users can connect to a wide variety of internet sites, using encryption, without needing to somehow decide whether they themselves trust the certificate provided by the website.
The most important thing to remember is that in most cases the CA is not vouching for the quality or integrity of the website - they are just vouching for whether the person/group who controls the domain/server is also the person/group providing the certificate for encrypted communication with the website. Its a protection against MITM attacks and snooping, not a protection against phishing or anything else that might happen once the connection is established.
The way it’s setup can any CA verify any website, so the weakest link of your CA basically allows an attacker to mimic any website you connect to?
This is the compromise. In exchange for having the ability to easily establish an encrypted connection to pretty much any public web service, the tradeoff is that the entire public internet's encryption is only as good as the operations of the weakest of the big public certificate authorities.
This is assuming the CT logs no longer issue SCTs for these CAs. If they do then you just need to the CT dance and publish that certificate there.
Of course this assumes the app/device isn't using certificate pinning.
Why wasn't this second spend by the parties accepting those certificates as valid before they were accepted?
In this case I wonder if this was an intentional wide open doorway to fraud
They literally were too lazy to type more than just a single '4'.
https://.mozilla.org/showbug.cgi?id=2083449
These would look like nice random values (unlike the ones that were recently compromised), but they would be trivial to generate by anyone who knows the initial inputs (PRNG algorithm, seed, maybe starting byte position, etc.).
Why are browsers trusting CAs which issued zero certificates since their creation 1 year ago?
No one is going to suspect `98761316832165974216498789746` is anything other than random. But `000000000000000123` looks suspicious.
But the probability to receive one number or the other are the same.
smaller than 384 means 384 numbers (including 0) divided by the amount of possible numbers (see above) imho
If it was deliberate, one would use keys that only the person abusing it has. Not keys everyone can guess if they get a hint.
Here, you didn't leak anything, you just fucked up.
If I'm going to ask you or force you to share your password with me, there's no reason I'd ask you to set the password to 4. We might as well agree that the password would be D#!(s9fj0jalk!4af095SF42 , and it's much more likely our collaboration will continue working for years.
"Never attribute to malice that which is adequately explained by stupidity"
No need for trustworthiness, then. /s
In all likelihood it is code that reads 1 byte from /dev/random, or reads 32 bytes but writes it into a 1 byte array, or something to that effect.