SNI, ESNI, and ECH Explained

Why SNI Was Needed: Virtual Hosting

IPv4 address scarcity and the economics of hosting led to virtual hosting, where a single IP address serves hundreds or thousands of different domain names. For plain HTTP this was trivial — the Host header in the request tells the server which site the browser wants. HTTPS created a problem: the server needs to present the correct TLS certificate before the encrypted connection is established, but the Host header is inside the encrypted payload and cannot be read yet.

Server Name Indication (SNI), defined in RFC 6066, solves this by adding the requested hostname as a plaintext extension inside the TLS ClientHello message. The ClientHello is sent before any encryption is negotiated, so the server can read the SNI value, select the matching certificate, and complete the handshake correctly. Without SNI, a shared server could only present one default certificate, causing errors for all other domains on that IP.

SNI in the TLS Handshake

The TLS ClientHello is the first message a browser sends when opening an HTTPS connection. It contains the TLS version the client supports, a list of cipher suites, random data for key derivation, and extensions — including SNI. Because this message travels before the session keys are established, it is entirely plaintext on the wire. Any network device between the client and server — ISP infrastructure, corporate firewall, national filtering system, or a coffee shop router — can read the SNI hostname.

This is the surveillance and filtering surface that ESNI and later ECH were designed to close.

SNI vs ESNI vs ECH

How ISPs and Firewalls Use SNI for Filtering

Network-level content filtering using SNI is straightforward to implement. Deep packet inspection hardware reads the plaintext SNI extension from TLS ClientHello messages and compares the hostname against a blocklist. If the hostname matches, the connection is reset or silently dropped — no need to decrypt the traffic. This technique is used by national filtering systems in multiple countries, by corporate web proxies, and by consumer ISP parental controls. The method is fast, cheap, and does not require intercepting the encrypted session content. ECH is designed specifically to prevent this class of inspection.

ESNI: The First Attempt

ESNI (Encrypted Server Name Indication) was an experimental extension that encrypted the SNI value using an asymmetric public key published in a DNS TXT record. The client fetched the key, encrypted the server name, and sent the ciphertext in place of the plaintext SNI. ESNI was deployed by Cloudflare and supported in Firefox. However, it had a fundamental design limitation: it encrypted only the SNI field while leaving many other potentially sensitive ClientHello extensions exposed. It was also brittle in practice and was superseded before wide adoption.

ECH: Outer and Inner ClientHello

Encrypted ClientHello (ECH), standardised in RFC 9258, takes a different architectural approach. Instead of encrypting one field, it wraps the entire sensitive ClientHello — called the inner ClientHello — inside an encrypted extension of a public outer ClientHello.

• The outer ClientHello contains a public-facing SNI that identifies the CDN or hosting provider (for example, cloudflare-ech.com), not the actual website. It is used for routing to the correct front-end server and is readable by the network.
• The inner ClientHello contains the real hostname (for example, example.com), the full list of cipher suites and extensions, and any other sensitive parameters. It is encrypted using a public key from the server's DNS HTTPS record and is readable only by the target server.

The ECHConfig public key is published in the DNS HTTPS (SVCB) record for the domain. The client fetches this record — ideally over DNS over HTTPS to prevent the DNS query itself from leaking the hostname — then uses the key to encrypt the inner ClientHello before sending the connection.

ECH and DNS HTTPS Records

ECH depends on DNS HTTPS records (record type 65, formerly called SVCB). These records carry service binding information including the ECHConfig blob. A record for example.com might indicate the ALPN protocols supported (h3, h2), the target address, and the ECH public key and configuration. Browsers that support ECH look for this record before connecting. If the record is absent or the network blocks it, the browser falls back to a standard TLS connection without ECH.

Browser Support and ECH Implications for Censorship

ECH is enabled by default in Firefox and Brave. Chrome enables ECH when connecting to servers that advertise it via DNS HTTPS records. Safari support is in progress. Server-side, Cloudflare has deployed ECH broadly across its network, covering a substantial fraction of HTTPS traffic on the internet.

ECH significantly raises the cost of SNI-based filtering because the visible SNI points only to the CDN infrastructure, not the individual site. Blocking the CDN's IP range to suppress one site would block all sites on that infrastructure. Some national filtering systems have responded by blocking ECH connections entirely or by blocking the DNS record type. This creates a cat-and-mouse dynamic where ECH and encrypted DNS together improve privacy but may trigger more aggressive blanket blocking by some network operators.

What ECH Does Not Hide

• Your IP address is still visible to everyone on the path.
• The CDN or hosting provider's IP range is still visible, which may identify the general infrastructure used.
• DNS queries for the domain remain visible unless encrypted DNS (DoH or DoT) is also used.
• Traffic volume and timing can still be used for traffic analysis.
• ECH provides no benefit if the browser, server, or DNS infrastructure does not support it.

Frequently Asked Questions

What does SNI stand for?

SNI stands for Server Name Indication. It is a TLS extension that lets a client tell a server which hostname it wants during the TLS handshake, enabling virtual hosting on shared IP addresses.

Is ESNI still used?

ESNI was an earlier experimental design for encrypting the server name. It has been replaced by Encrypted ClientHello (ECH), which encrypts the entire inner ClientHello rather than just the SNI extension.

Does HTTPS hide the domain I visit?

HTTPS hides page paths, form data, cookies, and response content, but without ECH the hostname is still visible in the plaintext SNI extension of the TLS ClientHello. DNS queries also reveal the domain unless encrypted DNS is used.