SNI (Server Name Indication)

What is SNI?

Server Name Indication (SNI) is an extension to the TLS handshake that lets a client tell the server which hostname it’s trying to reach — at the start of the connection, before encryption is established. This solves a chicken-and-egg problem that once blocked hosting multiple HTTPS sites on one IP address: the server needs to present the right TLS certificate for the requested domain, but it can’t know which domain the client wants until the client says so, and in early TLS the client didn’t say so until after the certificate was already sent. SNI fixes this by putting the target hostname in the opening ClientHello message, so the server can pick and present the correct certificate.

Why it made modern web hosting possible

The historical significance is large. Before SNI, each HTTPS website effectively needed its own dedicated IP address, because a server presenting a certificate couldn’t tell which of several hosted sites a connection was for — it had one IP, one certificate. With the IPv4 address shortage, dedicating a scarce public IP to every TLS site was wasteful and expensive. SNI enabled name-based virtual hosting for HTTPS: one server, one IP address, serving hundreds of different domains each with its own certificate, selected on the fly based on the SNI hostname in the handshake. This is the mechanism underpinning shared hosting, CDNs, and cloud load balancers — a single Cloudflare or AWS edge IP fronts enormous numbers of distinct HTTPS sites precisely because SNI lets it choose the right certificate per connection. It’s the TLS-layer parallel to the HTTP Host header (which does name-based routing for unencrypted HTTP); SNI does the equivalent selection for the encrypted connection’s certificate.

The privacy problem — and Encrypted Client Hello

Here’s the subtlety that makes SNI a current topic rather than settled plumbing: the SNI hostname is sent in cleartext. Because it travels in the ClientHello before the encrypted channel exists, anyone observing the network — an ISP, a network operator, a censor, a snooper on public Wi-Fi — can read which website you’re connecting to, even though everything else in the TLS session is encrypted. So while TLS hides the content of your browsing, plain SNI leaks the destination. This is exploited both for censorship (blocking connections based on the SNI hostname) and surveillance/tracking. The fix being deployed is Encrypted Client Hello (ECH) — the successor to the earlier “Encrypted SNI” (ESNI) — which encrypts the SNI (and the whole ClientHello) so the destination hostname is no longer exposed to on-path observers. ECH adoption is growing (Cloudflare and browsers have pushed it) but isn’t yet universal, and it’s caught up in the same tension between privacy and network operators/censors who rely on seeing SNI. For engineers, the practical points: SNI is required for essentially all modern TLS hosting (extremely old clients that don’t send it will get the wrong cert or fail), and if destination privacy matters, ECH is the emerging answer.

What people get wrong

• Assuming TLS hides which site you visit — classic SNI sends the hostname in cleartext, so observers see your destination even though the content is encrypted.
• Forgetting SNI on very old clients: clients that don’t send SNI can receive the wrong certificate on a shared IP and fail to connect.
• Confusing SNI with the Host header — SNI selects the certificate during the TLS handshake; the HTTP Host header routes the request after encryption is set up.

Primary source: RFC 6066: TLS Extensions (Server Name Indication)