HTTPS does not hide which site you are visiting

The padlock is one of the most successful pieces of security communication ever made, and it has taught a great many people something slightly wrong. HTTPS protects what you send. It has never protected where you sent it, and on an ordinary connection the destination is visible to anyone on the network path.

Worth being precise about what falls on each side of that line.

What is genuinely protected

Once the TLS handshake completes, everything above it is encrypted: the path and query string, every header, your cookies and auth tokens, the request body, and the entire response. Somebody watching the wire cannot tell whether you loaded an article or submitted a form, cannot read anything you typed, and cannot modify any of it without the connection failing.

That is a lot, and it is why HTTPS everywhere was worth the decade it took.

What leaks anyway

The DNS lookup. Before connecting to anything, your machine asks a resolver for an address, and by default that question travels in plaintext. DNS-over-HTTPS and DNS-over-TLS encrypt it, and both are now common in browsers — but they move the knowledge rather than removing it. Your resolver still sees every name you ask for, and you have chosen who that resolver is.

The IP address. Unavoidable. Packets need a destination, and that destination is in the clear on every one. Sometimes an address identifies a site outright. Sometimes it identifies a large CDN serving millions of sites, which genuinely blurs things — one of the underappreciated privacy effects of the modern web is that shared infrastructure hides individual sites in a crowd.

The server name, in the handshake itself. This is the one that surprises people. In the very first message of a TLS connection, the client sends the hostname it wants, in plaintext, in a field called Server Name Indication.

It is there for an unavoidable reason. One IP address may serve thousands of sites with different certificates, so the server has to know which certificate to present — and it has to know before encryption exists, because the certificate is how encryption gets established. Chicken and egg. TLS 1.3 encrypts far more of the handshake than 1.2 did, and it still sends this in the clear.

The shape of the traffic. Even with everything above fixed, the sizes and timing of the packets you exchange are visible, and pages have recognisable fingerprints. This is a real research area rather than a theoretical concern, though it takes considerably more effort than reading a hostname.

What Encrypted Client Hello changes

ECH is the fix for the SNI leak, and it works by breaking the circularity rather than wishing it away. The client fetches a public key for the server ahead of time — through DNS, in an HTTPS resource record — and uses it to encrypt the real handshake inside an outer one that names something generic, typically the CDN rather than the site.

Two things worth knowing. It only works if your DNS is also encrypted, or you have simply moved the leak one step earlier and left it there. And deployment is partial: it needs support from the browser, the DNS resolver and the server operator simultaneously, so at the moment it protects some of your connections and not others, with nothing in the interface telling you which.

The practical version

On a normal connection, an observer on your network — your ISP, a coffee shop router, a corporate network, whoever runs the VPN you installed — can build a reliable list of the sites you visit. They cannot see the pages.

So “my ISP can see I read a lot of the Guardian” is true. “My ISP can see which articles” is not.

Two things people reach for that are worth being clear about:

• A VPN relocates the observer, it does not remove one. Everything above is now visible to the VPN provider instead of the network you are on. That is a real improvement on an untrusted airport network and no improvement at all against a provider you have less reason to trust than your ISP.
• Corporate interception is a different mechanism entirely. If your employer installed a root certificate on your machine, their middlebox can terminate TLS, read everything in full, and re-encrypt to you with its own certificate — and the padlock still appears, because from the browser’s point of view nothing is wrong. This is not a weakness in TLS. It is TLS working exactly as specified for someone who controls which certificate authorities you trust. It is also checkable: look at who issued the certificate for a site you are on.

The sentence to keep

HTTPS is an envelope, not an unmarked one. Nobody can read the letter. Everybody on the route can read the address.