SNI Inspection: Why Censors Can See Your Destination Even With HTTPS

Imagine sending a letter in a locked box. The box is sealed so no one can read your message inside. But the address label on the outside remains visible to everyone who handles it—the postal worker, the sorting facility, anyone in the delivery chain. Even if your message is completely private, your destination is not.

This is the core problem with SNI inspection. HTTPS encrypts the content of your web traffic—what you type, what you read, what you submit—but the domain name you're visiting travels in plain text as part of the encryption handshake itself. Censors and network administrators can read this domain name and block you before you ever see the first encrypted byte. A VPN doesn't solve this problem at the DNS level either, because SNI operates lower in the network stack, during the actual connection to the website's server.

Why Domain Names Leak During Encryption

To understand SNI, you need to know why it exists in the first place. Most websites on the internet don't run on their own dedicated server. Instead, thousands of different websites share a single server and a single IP address. When your browser connects to that IP address, the server has no way of knowing which website you're trying to visit—until you tell it.

The server name indication (SNI) is your browser's way of saying "I want to connect to example.com" during the TLS handshake, the cryptographic negotiation that sets up HTTPS. The problem: this happens before encryption kicks in. SNI is sent in plain text. It appears in network packets that pass through your internet service provider, your country's network infrastructure, and any other system monitoring traffic along the path.

Think of it as a phone book. When you call a business that shares a phone line with other businesses, you have to say the business name out loud before the receptionist transfers you. Everyone on the line hears which business you called, even if the conversation that follows is private.

How Censors Use SNI Against You

A government or ISP that wants to block certain websites doesn't need to decrypt your traffic or compromise HTTPS. They simply watch the SNI field in every TLS handshake passing through their network. When they see a domain on their blocklist, they reset the connection or refuse to route it.

This is cheaper and simpler than breaking encryption. It works at the network edge, before the connection even reaches the destination server. Countries like China, Russia, Iran, and Turkey have all been documented using SNI-based blocking. In many cases, the blocking is immediate and invisible—your browser doesn't receive a clear error message; the connection simply times out.

SNI inspection also allows ISPs and network administrators to implement blocking without needing access to the actual content of your traffic. They don't care what you're reading on a blocked site. They only care that you're connecting to it.

Why SNI Is Harder to Fix Than You Might Think

The obvious solution is: encrypt the SNI too. And researchers have been working on exactly that. But it turns out the internet's architecture creates real obstacles.

One problem is backwards compatibility. Millions of servers, load balancers, and network devices still need to read the SNI to route traffic correctly. If you encrypt SNI, older infrastructure breaks. You can't flip a switch and update the entire internet simultaneously. Instead, new encryption methods have to coexist with old ones during a transition period that could last years.

Another issue is performance and complexity. Encrypting SNI requires changes to the TLS protocol itself and coordination across browsers, servers, and certificate authorities. Different layers of the internet need to know how to handle it.

Encrypted Client Hello and the Path Forward

The IETF (Internet Engineering Task Force), which sets internet standards, developed Encrypted Client Hello (ECH) as a fix. ECH encrypts not just the SNI but the entire initial message your browser sends to the server. The server can still identify which domain you're connecting to, but the network in between cannot.

Earlier efforts like ESNI (Encrypted SNI) aimed at the same problem but had limitations. ECH is the more complete solution, but it requires both the website and your browser to support it. As of now, support exists but remains patchy. Many websites haven't implemented it yet.

Even with ECH, tradeoffs remain. Blocking becomes harder but not impossible—censors can fall back to blocking by IP address alone, though that's less precise and more likely to catch legitimate websites by accident. Some network operators argue they need SNI visibility for legitimate reasons like malware detection and network management, creating tension between security and network administration.

What This Means for You

SNI inspection shows why encryption alone doesn't guarantee privacy on the internet. Even strong encryption can fail if metadata—information about your traffic rather than the content itself—leaks at a different layer. HTTPS protects what you do on a website, but not which websites you visit from network-level observers.

Tools like VPNs can hide SNI from your ISP by tunneling all traffic through an encrypted connection to another server. DNS-over-HTTPS can hide what domains you search for. But understanding the mechanism—that domain names travel in plain text during the TLS handshake—helps you think clearly about which tools actually solve which problems.

As ECH and related technologies gradually deploy, SNI inspection will become less effective. But this is a years-long process, not a quick fix. For now, if you're in a country where domain-based blocking is common, relying solely on HTTPS won't protect you from censorship at the network level.