Most people think HTTPS hides where they’re going.
It doesn’t. Not completely.
The page content is encrypted. The cookies are encrypted. The request path is encrypted. But before any of that protection starts, the client still has to tell the server which hostname it wants. That hostname travels in plaintext inside the TLS ClientHello as Server Name Indication — SNI. Anyone on the network path can see which site you’re connecting to.
That’s the part HTTPS left hanging out in the wind.
Why SNI Exists
SNI solved a very ordinary hosting problem.
Once the web moved to virtual hosting, one IP address often served many HTTPS sites. The server needs to know which certificate to present before the handshake can proceed. If ten domains share one edge IP and the server doesn’t know whether the client wants a.example or b.example, it can’t choose the right certificate chain.
So TLS added an extension in ClientHello that says: “I’m here for this hostname.” The server reads it, picks the matching certificate, and the handshake continues.
Simple. Necessary. And completely unencrypted.
The ClientHello is the very first message in a TLS handshake. It’s sent before any keys are exchanged, before any encryption is negotiated. The SNI field inside it is readable by anyone watching — your ISP, your corporate proxy, a national firewall, the coffee shop router.
What This Leaks
HTTPS protects the content of your communication. SNI leaks the destination.
Your ISP can’t see which pages you visit on a site. But they can build a complete list of every site you visit. That’s enough for profiling, targeted advertising, or surveillance. In some jurisdictions, it’s enough for censorship.
This is exactly how censorship systems work. The Great Firewall of China, corporate content filters, and ISP-level parental controls all inspect the SNI field to decide what to block. They don’t need to break encryption. The hostname is right there, in cleartext, in the first packet.
Even if you use DNS-over-HTTPS to hide your DNS queries, the SNI field still reveals the destination. You encrypted the question (“what’s the IP for example.com?”) but then announced the answer in your very next packet.
Domain Fronting: The Hack That Died
For a while, there was a clever workaround.
Domain fronting exploited the gap between SNI and HTTP. You’d put one hostname in SNI (say, a popular CDN domain that censors wouldn’t block) and a different hostname in the HTTP Host header (the actual destination, hidden inside the encrypted tunnel). The censor sees the SNI and lets the connection through. The CDN reads the Host header and routes to the real site.
Signal used this to bypass censorship in several countries. Other circumvention tools did too.
Then the cloud providers killed it. Amazon, Google, and Microsoft all disabled domain fronting because it violated their terms of service. Fair enough — it was effectively using their infrastructure to launder traffic. But when they shut it down, they also shut down a tool that dissidents relied on.
Encrypted Client Hello: The Real Fix
The proper solution is Encrypted Client Hello — ECH (previously called ESNI).
The idea: encrypt the SNI field itself. The client fetches a public key from DNS (published in an HTTPS or SVCB record), uses it to encrypt the inner ClientHello containing the real hostname, and wraps it inside an outer ClientHello that shows only a generic cover name — usually the CDN’s shared hostname.
The observer sees: connection to cloudflare-ech.com (or whatever the cover is). The actual destination is encrypted. Only the server, which has the private key, can read it.
On paper, ECH closes the last major plaintext leak in HTTPS.
Why ECH Is Taking Forever
ECH requires coordination across three layers that don’t coordinate well:
DNS infrastructure. The server’s ECH public key must be published in DNS via HTTPS/SVCB records. Not all DNS providers support these record types yet. Not all resolvers handle them correctly.
CDN support. ECH works best when the CDN terminates TLS. Cloudflare has been experimenting with ECH since 2020. Adoption across other CDNs is slow.
Browser rollout. Firefox has ECH support. Chrome is working on it. But both depend on the DNS and CDN layers being ready. A browser can’t use ECH if the server doesn’t publish a key.
The middlebox problem. Enterprise proxies and firewalls inspect SNI for content filtering. ECH breaks that. Enterprise IT will resist any change that makes their filtering infrastructure useless. Expect corporate networks to block ECH connections entirely rather than lose visibility.
This is the political dimension. ECH improves privacy for users and degrades control for network operators. Those operators have opinions, and they lobby browser vendors.
The Current State
In 2026, SNI still leaks your destination on the vast majority of connections. ECH is deployed on a fraction of traffic — primarily Cloudflare-hosted sites with Firefox users. Universal deployment is years away, if it happens at all.
The practical reality: HTTPS protects the content. It does not protect the metadata. Where you go is still visible to anyone on the path. DNS-over-HTTPS hides your queries. ECH would hide your destination. Neither is universally deployed.
We encrypted the letter but wrote the address on the outside of the envelope. Twenty years later, we’re still arguing about whether to encrypt the envelope too.