• I don’t get it… How does this protect anything? If we want our packets to reach a web server, we need to write the server’s IP address on them. If a snooper has the IP, can’t they just lookup the domain name from a DNS server? Or is that not a service DNS provides?

    If the IP address is encrypted, how will the routers know where to send the packets? Only solution I can think of would be onion routing… Am I wrong??

    • An IP address is no longer associated with just one website/domain name. There could be thousands of websites running on a single IP address.

      As is, anyone can currently look at your encrypted traffic and see in plain text which site you’re surfing to. So this proposal is long overdue.

    • somebody wiresharking your traffic can see the domain name you’re contacting even if you use https; this solves that.

      reverse DNS lookup does exist, but it’s not always accurate, especially when multiple websites are hosted on the same server (which is more common than you think)

      • Is it because of the “Host” HTTP header? I always thought it was optional, since the IP address and port were handled by the network and transport layers respectively. Turns out it’s required to resolve between different virtual hosts in the same server. Today I Remembered (TIR?) that virtual hosts are a thing…

        Is there anything else that might indicate the domain name in the handshake connection?

        • Is there anything else that might indicate the domain name in the handshake connection?

          The SNI (Server Name Indication) happens before any HTTP communication and is done in plain text. It is needed because a single web server might host multiple websites, since each of them has their own certificate it needs to know which one to serve you.

          With the new proposal that SNI is now encrypted. It makes the difference between anyone listening in being able to tell “you visited lemmy.world” and “you visited something behind Cloudflare”.