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.
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.
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.
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.
- 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.
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 will say, there’s something almost reassuring when something goes boom that badly and the story is really silly. It’s like [horrific human-caused disaster] but it’s because of a Three Stooges episode.
The 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.
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
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.
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".
Kind of hard to understand how a bug would have generated a second pair of key so bad, and how would human would have ended up using them. Never attribute to malice what can be attributed to stupidity, but sometimes you wonder.
And an equal amount of stupidity in the whole ecosystem, apparently there are no "unit-tests" for trivial failure modes, like 8 bits of entropy, before adding a CA to the trusted list.
What next, googling the public key finds a 2 year old pastebin with the private key?
It reads okay to me too, yet Pangram says it's mixed - the "What a private key actually is" section is AI, so is 'Why "it cannot be contained"' and some others.
I 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.
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?
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.
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.
“eMudhra intermediate CA compromise” | 947 points | 19 hours ago | 408 comments
There are two hard problems in computer science: naming things, cache invalidation, and off-by-one errors.
https://xkcd.com/221
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.
- 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.
https://xkcd.com/221/
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.
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.
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.
Why are browsers trusting CAs which issued zero certificates since their creation 1 year ago?