Little eMudhra was asked to write down his a secret and hand it in to the teacher. He accidently gave the teacher the wrong paper.
Comment on PSA: eMudhra Intermediate CA Compromise
artyom@piefed.social@piefed.social 3 weeks ago
ELI5?
greybeard@feddit.online 2 weeks ago
- artyom@piefed.social@piefed.social 2 weeks ago
Naughty boy
thenextguy@lemmy.world 3 weeks ago
Not possible.
rtxn@lemmy.world 3 weeks ago
The encryption that SSL/TLS provides (that puts the “secure” in HTTPS) uses a public–private key pair and a mathematical function that is easy to calculate, but difficult to calculate its inverse. Generating the key pair requires a cryptographically secure random number that is impossible or very difficult to guess, which must be kept secret at all times. If this random number is leaked or guessed by a malicious actor, the private key can be reconstructed and used to impersonate a website or break the encryption.
One of the factors that determine the security of the key is the size of the number, i.e. the number of digits. In this case, a proper key should’ve had a length of 384 bits (or 116 decimal digits). In reality, the keys that eMudhra used had eight bits, which can only represent 256 possible values, and can be easily guessed even by brute force. The specific private keys were the numbers 4, 56, 66, 115, 155, 156, 230, and 237.
Triumph@fedia.io 3 weeks ago
... Eight? Eight???
rtxn@lemmy.world 3 weeks ago
Four… Fucking… Pixels?
The working hypothesis is that this was some sort of debug or test key that was never meant to be used in production, being used in production.
www.youtube.com/watch?v=87H6m2v4zNs
klugerama@lemmy.world 2 weeks ago
It’s also worth mentioning that these very poorly secured certificates were intermediate certificates. These are not used directly by websites to assure the end user that the communication with the website is secure - it’s even worse than that.
Intermediate certificates are used to sign the website certificates, so that the end user’s browser can look up the server certificates that websites give them, to determine if the certificate is genuine (and not, say, a man-in-the-middle that is intercepting the communication and merely pretending to be the real website).
Since anybody can easily just create a certificate, there has to be a way that an end user can be confident that the website they are visiting is actually the one they intend to visit. The way the current system works is that there is a curated list of CA (certificate authority) certificates that have been thoroughly vetted by multiple security organizations. These are used to “sign” server certificates. Every browser has a copy of the corresponding public CA certificate. The private certificates are kept very securely offline. There’s no easy way for anyone to create a certificate that “claims” to be (but actually isn’t) signed by one of these trusted CA certificates. This way, when a website provides its certificate, the browser can look at the signing key and know with a high degree of certainty that the website is what it says it is.
An intermediate certificate is a “delegate” subsidiary of a CA cert. It can be used as a proxy to its parent CA cert to sign other generated certs. So even if a website (or a man-in-the-middle) provides what appears to be a very secure cert with strong encryption, it may have been signed by a “broken” insecure intermediate cert. The browser, of course, doesn’t know - or care - about how insecure the the intermediate cert is - the browser has already implicitly trusted it. There fore, the browser has no way of knowing or alerting the user that their communication with the website has been compromised by someone pretending to be another website.