Say Alice wants to open up an HTTPS connection to Bob through a proxy named Earl.

What prevents Earl from reading alices request, opening a connection pretending to be bob, and then opening a https connection with bob pretending to be Alice , and snooping on the traffic as it passes through ?

  • Sigmatics
    link
    fedilink
    arrow-up
    3
    ·
    edit-2
    11 months ago

    The security of HTTPs relies on public key certificates.

    I recommend reading up on it here: https://en.m.wikipedia.org/wiki/HTTPS#Overview

    Especially the part after this segment:

    Web browsers know how to trust HTTPS websites based on certificate authorities that come pre-installed in their software.

    • bellsDoSing@lemm.ee
      link
      fedilink
      arrow-up
      1
      ·
      11 months ago

      Great explanation indeed!

      I was missing this part from my understanding:

      The certificate correctly identifies the website (e.g., when the browser visits “https://example.com”, the received certificate is properly for “example.com” and not some other entity).

      In a sense it all comes down to a CA (e.g let’s encrypt) not giving out certificates for your domain, so that only your server has a valid certificate for your domain and not also some attacker.

      But that itself requires domain verification to be secure (robust against MITM attacks), which apparently it wasn’t for the longest time.

      Just recently there was a post about ACME-CAA, which addresses this issue (when configured). Great article on it here: https://www.devever.net/~hl/acme-caa-live

      • Sigmatics
        link
        fedilink
        arrow-up
        1
        ·
        11 months ago

        Yeah, pretty much. If you control the DNS you can do whatever