They can see
What website you’re going to (e.g. pornhub.con)
They cannot see, if using HTTPS
I wish this was true but alas, it is not.
As the Internet functions today for the vast majority of sites and users, it’s just as easy to determine what site an HTTPS request is going to as it is with HTTP. That’s not an exaggeration, it can be done trivially and passively with a basic traffic sniffer
With HTPS the way it is currently configured on the majority of sites, the content of the request/response is protected- as well as the most specific of the request metadata (the URL path) but the DNS name (e.g. www.pornhub.com, or whatever,) is not
There are roughly three ways to determine what site an HTTPS request is for, though in practice the third is the most reliable and precise since the first two are not always available and/or won’t always reveal the exact FQDN. Depending on the server configuration, the second method may only reveal the domain (e.g. pornhub.com) but not the FQDN (e.g. grannies.pornhub.com)
Those limitations with the first two methods are a result of local DNS caching (when using #1, the DNS leak) and wildcard certificates (when using #2, the TLS certificate DNS SAN leak)
The three ways to get this data:
- DNS queries. A DNS query is made immediately before the browser knows what IP address to connect to (plaintext, from client to DNS server and DNS server to client)
- The DNS SAN values in the certificate, which are required by modern browsers if you don’t want users to get an giant untrusted site warning page. For browsers to trust a site, the site’s certificate must contain (at least) the DNS name of the site being requested by the browser (plaintext, flowing from HTTPS server to browser)
- The most precise and common method uses the Server Name Indication (SNI) extension value, which all modern browsers send. It is sent even if the server/load-balancer isn’t actually using SNI for anything (plaintext, from browser to HTTPS server)
Unfortunately, the SNI issue will remain an issue until servers are configured to support TLS1.3 and Encrypted SNI (ESNI) in a default configuration
ESNI is new(ish), only supported in TLS1.3. TLS1.3 is becoming common but is still not universally adopted. ESNI is rare
Cloudflare is raising awareness and aggressively pushing ESNI adoption but it’s not likely to be used by all major sites for quite a while. That said, I haven’t checked the specific exemple (pornhub.com)
What are your options if you want to have privacy from your router/gateway and ISP? Aside from waiting for ESNI?
- Use a VPN to mitigate the issues entirely, but be aware that the VPN provider will be able to snoop on you in the same way. It’s a tradeoff
- Use DNS over HTTPS or another DNS tunneling mechanism to mitigate the DNS leak but be aware that this is an incomplete (if not pointless) solution since it does nothing to mitigate the SNI and certificate SAN leak
I’m always a bit surprised at the misconception that HTTPS offers privacy for anything other than the content of the request. TLS up to 1.2 didn’t even consider the metadata a privacy concern. The same is true of DNS, except DNS is worse and didn’t even concern itself with the integrity of the request/response- meaning it can be tampered with while in flight, not just exposed
EDIT: fix words and sentences, fixed baffling double post (oops!)
EDIT #2: I just reinterpreted your (confusing) phrasing and layout and am not sure you’re saying what I thought you were saying. If you aren’t, I’ll still leave this here as a potential resource for others not familiar with the issue