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. }

  • Badabinski@kbin.earth
    link
    fedilink
    arrow-up
    14
    ·
    1 day ago

    MITM HTTPS traffic without a key doesn’t really let you do much of anything, especially with stuff like HSTS. You can mess with DNS, but the whole certificate authority thing is meant to make it so you can’t redirect someone’s traffic to a malicious server.

    This leaked private key completely destroys that guarantee, making it extremely scary. ~Plus, saved traffic for any site signed by this key which didn’t use PFS will be subject to post-facto decryption.~

    edit: I don’t know wtf I was thinking, the decryption thing is nonsense.

    • BlueKey@fedia.io
      link
      fedilink
      arrow-up
      8
      ·
      1 day ago

      I don’t think so about the post-facto decrypt. Keyexchange runs with the certs of the destination server. The cerst affected by the leak are intermediate certs which give trust to a cert chain AFAIK.

      • Badabinski@kbin.earth
        link
        fedilink
        arrow-up
        8
        ·
        1 day ago

        You’re absolutely right, I had shit all mixed up in my head. Oops 😅 thank you for the correction.