3 ms·

They'll know the IP addresses, but unless the DPI the SNIs, they may not know the domainnames, especially when an IP serves multiple domains.

viraptor 7y ago
I disagree with the usage of DPI here like it's a significant barrier. Your ISP has access to both the IPs and the SNIs. They can dedicate resources to log them or not to. SNI requires only a little bit more processing power, but otherwise they "know" both.
- tialaramex 7y ago
  This work is landing in parallel with development of eSNI, encrypted SNI. If you have a Firefox with this stuff switched on (so it uses TLS 1.3, eSNI and uses CloudFlare's DoH server), and you go to a site that's proxied by CloudFlare, only CloudFlare [and the site] know which site that was, an ISP sees only that you connected to CloudFlare (duh) and did some HTTPS transactions. There will be SNI in the ClientHello, but it's generic, it doesn't say which CloudFlare service you wanted so it doesn't help an ISP to log that. The IP belongs to CloudFlare so they learn that, but the rest is a mystery. All the stuff that makes this go lives in DNS. For privacy you should use DoH to go fetch it. For authenticity you should use DNSSEC to verify it. Proposals are under development for how to land the final DNS changes with HTTP/3 in there as well, so that a single query protected by DoH + DNSSEC can tell a browser "For HTTPS speak QUIC on this IP address and send this fake SNI, then use this eSNI encryption key to hide the real hostname". But already the prototype with boring TLS 1.3 and HTTP/2 works just fine in Firefox builds with it enabled.
  - viraptor 7y ago
    I'm really looking forward to tls1.3, but there's still a bit of time before it gets widely adopted. CloudFlare proxy will help a lot where they handle the connection, but there's lots of services which will take years to upgrade.

viraptor 7y ago

I disagree with the usage of DPI here like it's a significant barrier. Your ISP has access to both the IPs and the SNIs. They can dedicate resources to log them or not to. SNI requires only a little bit more processing power, but otherwise they "know" both.

tialaramex 7y ago
This work is landing in parallel with development of eSNI, encrypted SNI. If you have a Firefox with this stuff switched on (so it uses TLS 1.3, eSNI and uses CloudFlare's DoH server), and you go to a site that's proxied by CloudFlare, only CloudFlare [and the site] know which site that was, an ISP sees only that you connected to CloudFlare (duh) and did some HTTPS transactions. There will be SNI in the ClientHello, but it's generic, it doesn't say which CloudFlare service you wanted so it doesn't help an ISP to log that. The IP belongs to CloudFlare so they learn that, but the rest is a mystery. All the stuff that makes this go lives in DNS. For privacy you should use DoH to go fetch it. For authenticity you should use DNSSEC to verify it. Proposals are under development for how to land the final DNS changes with HTTP/3 in there as well, so that a single query protected by DoH + DNSSEC can tell a browser "For HTTPS speak QUIC on this IP address and send this fake SNI, then use this eSNI encryption key to hide the real hostname". But already the prototype with boring TLS 1.3 and HTTP/2 works just fine in Firefox builds with it enabled.
- viraptor 7y ago
  I'm really looking forward to tls1.3, but there's still a bit of time before it gets widely adopted. CloudFlare proxy will help a lot where they handle the connection, but there's lots of services which will take years to upgrade.