What Still Names the Sites You Visit: SNI Explained

When your browser opens an encrypted connection, it has to tell the server which site it wants before the encryption is established — otherwise a server hosting many sites would not know which certificate to present. That field is called Server Name Indication, and it has traditionally been sent in the clear at the very start of the handshake.

The consequence is that encrypting your name lookups does not, by itself, hide which sites you visit. The name goes out again a moment later in the connection itself.

Why the field exists at all

One address can serve thousands of different sites. Shared hosting and content delivery networks make this the normal case rather than the exception, which is part of why an address tells you much less about a destination than it used to.

An encrypted connection begins with the server proving its identity for a particular hostname. If the server does not know which hostname the client wants, it cannot pick the right certificate. Server Name Indication solves that by having the client state the hostname in its first message.

That message is sent before any keys have been agreed, so historically it could not be encrypted. It was a practical necessity, not an oversight.

What it means for privacy

Anyone who can see your connection can read the hostname, even though everything after the handshake is encrypted.

That includes your internet provider, the operator of whatever network you are on, and any intermediate network the traffic crosses. They learn which sites you connected to and when. They do not learn which pages, what you typed, or what came back.

This is why encrypted DNS, on its own, is a partial measure. It stops the same parties from reading your lookups, and then the connection announces the name anyway. The gap is the main reason the comparison in DNS over HTTPS versus a VPN does not come out even.

Reverse lookups and address ownership add to the picture even without the field. If a connection goes to an address block belonging to one well-known service, the destination is not much of a secret — the point developed in what an ASN and reverse DNS reveal.

The encrypted successor

A newer mechanism encrypts the hostname in the opening handshake, generally called Encrypted Client Hello. It works by having the client fetch a public key for the destination — published in DNS — and using it to encrypt the sensitive part of the first message.

Two things follow from that design. It depends on being able to look up the key privately, so it pairs with encrypted DNS rather than replacing it: if your lookups are readable, the name is exposed before the handshake regardless. And it requires support on both ends plus a hosting arrangement that makes the encrypted name useful, which is why deployment is uneven.

Support is growing but not universal, so it is not something to rely on being active for any particular site. Treating it as a bonus rather than a protection is the safer posture.

What a VPN does to this

A VPN wraps the whole handshake, so the field is not visible to anyone on your local path. Your provider sees an encrypted stream to the VPN server, with no readable hostnames inside it — not in the lookups, not in the handshakes.

The exposure moves rather than disappearing. Traffic leaves the VPN server and continues to the destination, and at that point the handshake is exposed to the same degree it would have been from your own connection. The VPN provider, and networks beyond it, can see the names.

That is the recurring pattern with a VPN: it does not eliminate the observer, it changes who the observer is. The scope of what it substitutes and what it leaves alone is set out in what a VPN hides about your IP address.

Why this matters for how sites get blocked

Network filtering commonly reads this field, and knowing that explains which workarounds work.

Filtering can be implemented in several places. A resolver-based filter refuses to answer for certain names, and changing resolvers routes around it. A filter that reads the handshake sees the name regardless of which resolver you used, so changing resolvers does nothing. An address-based block ignores names entirely.

That is a useful diagnostic. If switching to a different resolver restores access, the filter was in DNS. If it does not, the filter is reading your traffic — and the name in the handshake is the most likely thing it is reading.

Because a VPN encrypts the handshake, it defeats both of the first two. Where VPN protocols are themselves recognised and blocked, providers respond with obfuscated servers that disguise the tunnel’s own traffic signature — a separate arms race one layer down.

Putting the layers in order

Four separate disclosures of the same hostname, each with its own fix.

1. The lookup. Readable unless you use encrypted DNS or a VPN. Seen by the network path and always by your resolver.
2. The handshake field. Readable unless the encrypted successor is in use, or the connection is inside a VPN tunnel. Seen by the network path.
3. The destination address. Always visible to the network path. Reveals the service when the address block belongs to one operator.
4. The connection at the far end. Visible to whoever is beyond your VPN server, if you use one.

Closing one and leaving the others open produces very little benefit, which is the practical lesson. Encrypted DNS with no VPN closes the first. A VPN closes the first three from your local network’s point of view and moves the fourth. Nothing closes all four, because someone always has to route your traffic to its destination.

The takeaway

“My DNS is encrypted” is not the same as “nobody knows what I visit”. The hostname is announced more than once, in more than one layer, and the fixes are layer-specific.

When you want to know whether an activity is visible to a particular party, name the party and walk the four disclosures above. It is a short exercise and it produces a much more accurate answer than any single tool’s marketing does.