• cron
    link
    fedilink
    English
    arrow-up
    1
    ·
    2 hours ago

    With an enterprise CA this is not a huge trouble, but not exactly easy either.

    • hperrin@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      2 hours ago

      The CA just signs the certificate. They don’t have access to the private key, and thus can’t decrypt the key exchange.

      The key exchange is the only thing decrypted by the private keys. From that point on, everything is encrypted and decrypted by the agreed upon cypher using the exchanged key, which is randomly generated for each session.

      • cron
        link
        fedilink
        English
        arrow-up
        1
        ·
        18 minutes ago

        Surely they can do a man-in-the-middle attack and gemerate the required private keys and certs on the fly.

      • jaybone@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 hour ago

        Not that it really matters to this conversation but seems like you would know, so I’ll ask because I’m curious…

        Is that randomly generated per session key generated by the remote host ssh server? Is it a symmetric key (maybe for performance purposes)?

        • hperrin@lemmy.world
          link
          fedilink
          English
          arrow-up
          1
          ·
          edit-2
          5 minutes ago

          Technically, either side can request that the other generate a key and use that one, and it will cost an additional round trip. But generally in practice, each side generates their own key and tells the other side that it will be using that key.

          Yes, those keys are for symmetric encryption, and yes, it’s for performance. It’s way faster to just exchange keys with asymmetric encryption rather than do the whole stream.

          Also, I think you meant SSL, not SSH. SSH Uses a different key exchange protocol.

          I love cryptography. :)