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/

Xkcd 221: int getRandomNumber() { return 4; // chosen by fair dice roll. guaranteed to be random. }

    • mlg@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      4 hours ago

      Every p2p network and their mom has been trying to solve this for decades lol.

      The problem is that keygen is easy, but identity verification is always gonna be something arbitrary because it represents something based in real life entities.

      Even with TLS, people only trust google.com as being Google because they learned that Google uses google.com.

      I could make a goggle.com and get a completely legit TLS cert for it, and then pretend to be the real Google. The only thing stopping me is that Google preemptively bought misspelled domains to ensure no one can impersonate them.

      The lazy solution already exists. Just don’t use PKI and use direct trust on first connect like SSH.

    • jj4211@lemmy.world
      link
      fedilink
      English
      arrow-up
      15
      ·
      11 hours ago

      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.

      • mschae@discuss.mschae23.de
        link
        fedilink
        English
        arrow-up
        5
        ·
        11 hours ago

        Something like DANE, maybe? Only the websites actually using the compromised certificates would be compromised.

        • The_Decryptor@aussie.zone
          link
          fedilink
          English
          arrow-up
          3
          ·
          8 hours ago

          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.

          • mschae@discuss.mschae23.de
            link
            fedilink
            English
            arrow-up
            1
            ·
            edit-2
            8 hours ago

            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.

            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.