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 client and server share any key, so nothing in it can be encrypted the normal way. 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 a big part of how censorship and filtering systems work. The Great Firewall of China, corporate content filters, and ISP-level parental controls all inspect the SNI field, alongside IP addresses and DNS, 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.
TLS 1.2 was even leakier: the server’s certificate, with every hostname it covers, also crossed the wire in plaintext. TLS 1.3 encrypts the certificate, which left SNI as the one obvious leak. The IP address you connect to is visible either way; on a shared CDN address it says little, on a dedicated server it can say everything.
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 from 2016 to get past blocks in Egypt, the UAE, Oman, Qatar and Iran. Tor’s meek transport and other circumvention tools did too.
Then the cloud providers killed it. In April 2018 Google changed its infrastructure so fronting stopped working, saying it had never been a supported feature, and Amazon rolled out CloudFront changes the same month and told Signal that fronting violated its terms. Microsoft announced in 2021 that Azure would stop allowing it. Fair enough, in a way: it was using their infrastructure to disguise 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. It grew out of an earlier draft called ESNI and was finally published as RFC 9849 in March 2026.
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 a large provider terminates TLS for many sites behind one cover name; that crowd is the whole point. Cloudflare turned ECH on across its plans in 2023. Elsewhere adoption is slow, and a site on its own IP address gains little, since the address gives it away.
Browser rollout. This layer is actually done: Chrome enabled ECH by default in version 117 and Firefox in version 119, both in late 2023 (Firefox only uses it with DNS-over-HTTPS turned on). But 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 most connections. The browsers are ready; the servers mostly aren’t. Outside Cloudflare, ECH deployments are rare. Universal deployment is years away, if it happens at all.
If you want to see whether your own connection leaks, capture a TLS handshake in Wireshark and look at the server_name extension in the ClientHello. Or visit https://crypto.cloudflare.com/cdn-cgi/trace and look for sni=encrypted (ECH worked) versus sni=plaintext.
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.