- cross-posted to:
- technology@lemmy.ml
- cross-posted to:
- technology@lemmy.ml
Astonishingly, the private keys were 4, 56, 66, 115, 155, 156, 230, 237.
exploiting compromised certificates requires an active adversary-in-the-middle attack, meaning the attacker must act as a proxy between two TLS parties and receive encrypted traffic, decrypt it, reencrypt it, and send it to the other party. Such capabilities, in some cases, are usually limited to only the most well-resourced attackers. People with control of a local network—at a coffee shop, university, or other organization—face much less of a challenge.
https://emudhra.we-have-a-problem.com/
First: Who the fuck is eMudhra?
Second: What catastrophic failure of process allows a single point of failure Indian company to compromise the entire internet as we know it by accidentally releasing debug code? Why is it so fragile in the first place?
eMudhra is an intermediary certificate authority. some of the most popular intermediary CAs* are Sectigo, GlobalSign, MilesWeb, and GeoTrust. would you \^_^/ like to tell me who the heck ✨ these✨ are?
HTTPS has always had a failsafe called certificate revocation. it is working. at least, until the recent cultural shift of ethical hackers towards disclosing security vulnerabilities immediately for some reason
barring said cultural shift, the situation would not have been much different if any intermediary’s key leaked through normal means, which has happened
* LetsEncrypt is more popular than all of those, and Digicert and GoDaddy are more popular than half of those. But that’s where the name recognition ends.
Basically they learned that if they told the vendors and kept their mouth shut, many vendors won’t do shit and will just ignore the problem. Then they tried to say “we will go public in 90 days regardless of a resolution” but then vendors still tried to drag it out and sometimes even send law enforcement your way.
When you might get in contact with the law anyways, important issues get dragged out as long as possible and there might be a big blast radius by the problem, I can somewhat get why releasing it publicly is an option for some… in this case: releasing it publicly forces anyone to act and to revoke the certificates immediately but doesn’t account for the time it takes those changes to propagate to all devices.
What’s worse is that half the time people actively tried to tell vendors they got hit with a lawsuit in return. It usually doesn’t stick, but the sheer fact that you have to defend yourself in court cause you tried to help is nuts.
There is no reasonable way to be an ethical hacker when the companies you are hacking are not ethical themselves.
If they refuse to pay bounty programs, and refuse to fix the security vulnerabilities, there’s just no way to do security research.
If you don’t wanna get hit by security issues, get as far away as possible from these companies.
It is a problem we all have with dns, namely that the way it works now means we all must trust upstream CAs.
And unfortunately, we will probably suffer a few more of these before we switch over to a voting peer system.
DNS requires consensus (on who owns which name). So if by “voting peer system” you are talking about decentralized consensus, then blockchain is one of the only systems of such kind.
If you don’t want blockchain, then there’s no real choice other than a centralized system like CAs.
Eh, blockchain wouldn’t work here because changes to the ledger on the scale of DNS would take an astronomical amount of time to propagate. Blockchain would solve “source of truth” issues, but waiting 30 seconds or more every to.e you open your browser or curl to update the list of changes to the CRL wouldn’t be an acceptable working solution.
The problem of “voting peers” I mentioned would more easily be solved by a mechanism closer to how clusters decide which members are reliable and which should be deemed faulty. The problem is to instantly make changes to the CRL that are believable and take effect immediately.
Blockchain can’t do that in a timely way.
I believe you’re talking about RAFT. That requires trusting all nodes, so it’s not any different from how CAs already work. After all, the issue at hand is a compromised CA.
You lost me, none of that is true.
That’s not what happened at all. Read the article.
Warning, some oversimplifications ahead. Yes been warned.
First: It’s a certificate authority. It’s job is to issue the certificates needed for TLS (formerly SSL) to persons and companies so that you can use their services with an encrypted connection instead of plaintext.
Second: What exactly is the problem here? In the internet (or networking in general) your data passes a whole lot of “relays” before it reaches your destination. Everyone
mightwill snoop on this (see e.g. the Snowden leaks). So you have a desire: “Don’t talk unencrypted to random servers!”This now has two dimensions:
First: Don’t talk unencrypted to random servers.
Nowadays everything knows how to do this. You just start shouting random numbers at each other and then both know the same secret secret key although it was never mentioned. Then you use that key to encrypt the communication.
Second: Don’t talk unencrypted to random servers.
This one is harder. You resolved the server name to an IP and connected there. But… Was your connection intercepted? Were you told the correct IP? Who exactly are you talking with? This is where this incident gets scary: The server presents you a certificate (basically an id card, drivers license,…) telling you who it is. This certificate has been issued by a certificate authority (CA) that validated at least that this server belongs to the domain you’re trying to connect to (maybe more, e.g. the company running it,…). You do not trust this certificate alone, but your computer knows how to prove with some maths that it was really issued by a trusted CA it knows. If everything is alright, start the communication.
Scary: If one of those CA loses their key, anyone can issue certificates in their name. And everyone will trust those, as they seem genuine.
What that means is, that if I know their key (which has just been published), I can now intercept any traffic running through my machine, say that I’d be the server you want to talk to and now I can see everything. And all you’d see would be the padlock in the address bar telling you the connection is safe and trusted. And I can serve you anything. I could use that to just read everything and note your passwords or serve you a phishing site instead.
On a small scale, I would not be able to do much harm. I could set up an open WiFi at a cafe and get random people using that. But that’d be very localized and little effect. But since everyone can do this? Now every free wifi is potentially dangerous. You hack Starbucks and their customer wifi? Congratulations - you’re now doing this on a global scale! You hack an ISP? You can now fuck all their customers. Your a nation state actor? Well, have fun!
How can we defend against that?
Certificates can and will be revoked. They already are. In theory, everything is fine as no device with an up to date CA list will continue to trust those connections and will stop connecting. But it takes time to update all those lists. Your desktop running Windows, Mac or Linux? The update is probably already available. Your browser? Probably also already has the update available. But other devices? Your old EOL android tablet? The hand-me-down smartphones your kids got? Your smart home appliances that never got an update since you bought them 3 years ago?
Also there are more defenses - not everyone is using them, as they also may have some downsides:
DNSSEC - you can prove the IP is correct (assuming not this certificate was forged, too)
Certificate pinning - you can tell clients on their connections, that only this one specific certificate will be in use for the next days/weeks/months. Every forged certificate will then be declined (but also your new certificate because you had to unexpectedly renew it). Or at least say “All certificates for this server are issued only by Lets Encrypt. For every connection from now on: Don’t trust any other certificates even if they’re completely valid”
And a few more
Thank you for the explanation!