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/
SSL has had a broken trust model for decades. We need something truly decentralized and auditable.
Ok, but what would that look like in a way that would have mitigated this situation? Seems likely that such a system could actually exacerbate this specific scenario.
https://www.gnunet.org/
note: I understand none if this
SSL tries to solve several problems at once (identity verification + encryption of connection) over a protocol (TCP/IP) that isn't cryptographically tied together. Some very dedicated, smart people have sketched out some ideas on this. Basically, this compromise only happened because we're relying on a chain of third parties and intermediaries to do this verification of certs.
Web of trust, blockchain-based system (where a name like ebay.com can be registered and publish their own cert, so you can prove whoever owns ebay.com also owns that cert), a TCP/IP replacement that you can derive a key from (there are several interesting proposals here, some of which run on top of IP), are all ways of solving this problem with different tradeoffs.
This biggest problem like with any protocol change is inertia behind SSL. Same reason a number of excellent anti-spam protocol enhancements never made it to be widely accepted in SMTP and now everybody is fleeing to other methods of communicating without SMTPs issues.
Something like DANE, maybe? Only the websites actually using the compromised certificates would be compromised.
As nice as DANE is, it just shifts the burden of trust to your DNS provider. Like if you hop on Wi-Fi at a coffee shop, said network can simply MITM connections and supply their own certs via re-writing the DNS.
You can encrypt DNS to prevent that, but now you need a way to ensure your DNS client already trusts the desired DNS server, etc.
As much as people dislike CAs, they're a proven solution to a problem that's already implemented in nearly every device on the planet.
It can't, because DANE requires the use of DNSSEC. Unfortunately, there are still so many domains that do not have a proper DNSSEC configuration… so it's unlikely to work out well in practice, anyway.
edit: not to mention the DNS is centralized too. It's federated, at least (in the original sense of the word, not the way it is used on the fediverse), but ICANN is still the only central authority at the end.