SNI
Server Name Indication
A TLS extension that includes the target hostname in the ClientHello handshake message — allowing one server IP to host multiple HTTPS sites by presenting the correct certificate before the encrypted session begins.
SNI is included in the TLS ClientHello — the very first message in a TLS handshake, sent before any encryption is established. Before SNI existed, each HTTPS-enabled hostname required a dedicated IP address because the server had no way to know which certificate to present before the HTTP layer (where the Host header lives) was accessible. SNI sends the hostname early so the server can select the right certificate immediately. Today, a single CDN server behind one IP can host thousands of HTTPS domains simultaneously — all thanks to SNI.
Why SNI was needed
Before SNI, virtual hosting for HTTPS was impossible. HTTP/1.1 introduced the Host header to allow multiple websites on one IP address, but this header is inside the HTTP request — which only exists after TLS has completed. To complete TLS, the server must present a certificate. To select the right certificate, it needs to know which hostname is being requested. Without SNI, the server faced a circular dependency: it could not know the hostname until after the handshake, but needed the hostname to complete the handshake. The only solution was one IP per HTTPS site. SNI (RFC 6066, 2011) broke this circle by adding the hostname to the unencrypted ClientHello, before any certificate exchange.
TLS handshake with SNI
| Step | Who sends | Content | Encrypted? |
|---|---|---|---|
| 1. ClientHello | Client | TLS version, ciphers, SNI hostname | No (plaintext) |
| 2. ServerHello | Server | Selected cipher, certificate for SNI hostname | No |
| 3. Key exchange | Both | Session keys established | Partial |
| 4. Application data | Both | HTTP headers, body | Yes |
SNI-based filtering
Because the SNI hostname is transmitted in plaintext before encryption begins, it is trivially readable by any on-path observer — your ISP, corporate firewall, national filtering infrastructure, or a Wi-Fi access point. This makes SNI the most commonly used mechanism for network-level content filtering and censorship. A deep-packet inspection device reads the SNI field from the TLS ClientHello and compares it against a blocklist. If matched, the connection is reset (TCP RST) or redirected to a block page, without ever seeing the encrypted payload. This is why many blocked websites remain inaccessible over HTTPS even though the content itself is encrypted.
SNI and TLS 1.3
TLS 1.3 encrypts significantly more of the handshake than TLS 1.2 — including the certificate, which was sent in plaintext in TLS 1.2. However, the ClientHello itself — and therefore the SNI extension — remains unencrypted in standard TLS 1.3. The server's identity can be inferred from the certificate in TLS 1.2, but in TLS 1.3 the server's certificate is encrypted. This means the only remaining plaintext identifier in a TLS 1.3 connection is typically the SNI field, making it even more targeted for surveillance and filtering.
Encrypted SNI (ESNI) and Encrypted Client Hello (ECH)
ESNI was an early attempt to encrypt only the SNI field, but it was superseded by ECH (Encrypted Client Hello), which encrypts the entire ClientHello. ECH works by splitting the ClientHello into an outer (unencrypted, sent to a shared frontend like a CDN) and an inner (encrypted, containing the real SNI and other sensitive extensions). The inner ClientHello is encrypted using a public key that the server publishes in its DNS HTTPS resource record. An observer sees only that the client is connecting to a particular CDN IP — not which specific backend domain.
ECH requires DNS-over-HTTPS or DNS-over-TLS to prevent DNS queries from leaking the hostname that ECH is designed to hide. Cloudflare deployed ECH in 2023; Firefox enabled it by default in 2024. Chrome and other browsers are rolling it out. Server-side support requires publishing HTTPS DNS records with the ECH public key — currently primarily available through Cloudflare-hosted domains. Until ECH is universally deployed, standard SNI continues to leak the target hostname of every HTTPS connection.
Privacy and censorship implications
The practical implication of plaintext SNI is significant. Even on a fully encrypted HTTPS connection, your ISP can build a complete record of every website you visit by logging SNI values — without ever seeing page content. National firewalls use SNI to block specific domains without blocking entire IP ranges. Corporate proxies use SNI for application-aware filtering. When ECH is widely deployed, this surveillance vector disappears: the observer sees only the CDN endpoint, not the specific service. For users seeking privacy, using a browser with ECH support (Firefox), combined with encrypted DNS, provides the most protection available today against hostname-level tracking.
Frequently Asked Questions
Why is SNI necessary for HTTPS?
The server must present the correct TLS certificate before the encrypted session starts — but the HTTP Host header is inside the encrypted payload. SNI includes the hostname in the plaintext ClientHello so the server can select the right certificate before encryption begins.
Is SNI visible to network observers?
Yes — standard SNI transmits the hostname in plaintext, visible to your ISP and network admins. Encrypted Client Hello (ECH) hides it by encrypting the ClientHello using a public key in DNS, but ECH is not yet universally deployed.
What happens if a server does not support SNI?
It presents its default certificate regardless of the requested hostname. If the certificate doesn't match, clients get a certificate error. Modern infrastructure universally supports SNI — lack of SNI support is extremely rare today.