How SNI tells one IP address which site you meant

SNI (Server Name Indication) is the TLS extension that puts the hostname the client wants inside the ClientHello, the first message of the TLS handshake. It exists because of a deadlock that plain HTTP never had.

HTTP solved one-IP-many-sites back in the 1.1 era with the Host header: the server reads the header, picks the right virtual host, done. HTTPS broke that trick. The Host header is part of the HTTP request, the HTTP request is encrypted, and the encryption keys come out of a handshake in which the server must already have presented a certificate. A certificate is pinned to a name. So the server needs the name to pick the certificate, and the name is locked inside a payload it can't decrypt until the certificate is picked.

For years the workaround was crude: one IP address per HTTPS site. With IPv4 space already scarce, that put a hard ceiling on how many secure sites a host, or the internet, could carry. SNI breaks the deadlock by moving the name out of the encrypted payload and into the handshake itself, where the server can read it before any cryptography happens. It was specified in RFC 3546 back in 2003 and lives today in RFC 6066, the TLS extension definitions document.

SNI is extension number zero in the ClientHello's extension list: the server_name extension. It carries a list of names (in practice always exactly one), each tagged with a name type. Only one type was ever defined: host_name, a DNS hostname. RFC 6066 is strict about the contents — no trailing dot, and literal IP addresses are explicitly not permitted. If you connect to a raw IP, your client simply omits the extension.

Two properties of this layout matter more than the bytes themselves. First, it sits in the ClientHello, which means it is sent before key exchange, before certificates, before anything. There is no shared secret yet, so the extension is plaintext by construction — even in TLS 1.3, which encrypts nearly everything else in the handshake. This is not an oversight; it is the whole point. The name has to be readable precisely because nothing can be decrypted yet.

Second, it stopped being optional in practice. RFC 8446 (TLS 1.3) lists server_name among the mandatory-to-implement extensions, and every mainstream browser, HTTP client, and TLS library sends it by default. The clients that don't are museum pieces — and Part 07 covers exactly how they fail.

The extension was invented for certificate selection, but the infrastructure world noticed something better: the hostname is sitting in the first packet of the connection, readable without any keys. That makes SNI the cheapest routing signal in the entire stack, and three distinct patterns grew out of it.

SNI and ALPN get confused constantly because they travel together: both are ClientHello extensions, both are answered in the server's first flight, and both shape what the connection becomes. But they answer two entirely different questions.

Everything that made SNI useful to load balancers makes it useful to anyone else on the path. As the rest of the stack got encrypted — page contents under TLS, DNS queries under DoH and DoT — the plaintext SNI field quietly became the last reliable signal of which site you are visiting. A passive observer can't read what you do on a site, but the hostname itself is right there in packet one.

This is not theoretical. National firewalls and corporate middleboxes filter on the SNI field directly: read the hostname, compare against a blocklist, reset the connection. It is cheaper and more precise than IP blocking, because one CDN IP hosts thousands of innocent bystanders and the SNI names exactly the tenant to kill.

The cat-and-mouse response was domain fronting: put an innocuous hostname in the plaintext SNI, and the real, blocked hostname in the encrypted Host header, exploiting the fact that big CDNs routed on Host after terminating TLS. Censorship circumvention tools leaned on it for years, until the major clouds closed the mismatch — partly under pressure from the same governments it evaded. The episode proved the point in both directions: whoever can read the SNI controls the connection, and hiding the name needs to be a protocol feature, not a trick.

The fix had a false start. ESNI, the first attempt, encrypted just the SNI extension and left the rest of the ClientHello alone — which turned out to be both fragile and fingerprintable, and the design was abandoned. Its successor encrypts the entire inner handshake offer: Encrypted ClientHello, now standardised as RFC 9849.

The chicken-and-egg from Part 01 applies here too: you can't encrypt the first message of a handshake with keys from that handshake. ECH escapes the loop by getting key material out of band, from DNS.

Deployment status, as verified against the spec and its publication record: ECH is an IETF Proposed Standard (it spent years as draft-ietf-tls-esni before publication as RFC 9849). Firefox and Chrome ship client support, Cloudflare enables it across its edge, and clients GREASE the extension — sending decoy ECH values on ordinary connections — so that real ECH traffic doesn't stand out. The honest caveat: it only helps when the DNS lookup is also encrypted, and a passive observer still sees the destination IP. ECH shrinks the leak from "exact hostname" to "some site behind this provider", which is precisely as good as the provider is big.

Almost every SNI bug presents the same way: the wrong certificate came back. The tools below let you control the name you send independently of the address you connect to, which is the whole diagnostic game.

Pick an answer for each. The right one reveals a short explanation; the wrong ones do too. No scoring — these exist so the mental model travels with you.