Encrypted SNI and ECH

Why SNI is plaintext

In the earliest HTTPS, every site had its own IP address. The server already knew which site was being requested because only one site lived there. As the web grew, hosting providers and CDNs put many sites on shared IPs. The TLS handshake happens before the HTTP request, so the server has no other way to know which certificate to present — except an explicit signal in the handshake. SNI was added to TLS 1.0 in 2003 as that signal. It carries the hostname in plain text in the ClientHello.

It worked, but it left a glaring hole. Anyone watching the network can read the SNI and learn which site you're visiting, even though the rest of the TLS exchange is encrypted.

The ECH design

ECH wraps the sensitive parts of the ClientHello — including SNI — in an extra layer of encryption. The mechanics:

1. The site operator generates a key pair specifically for ECH. The public key is published in DNS as part of an HTTPS resource record on the site's domain.
2. The client fetches that DNS record (ideally over DoH/DoT) before connecting. It now has the public key.
3. The client constructs an "inner" ClientHello with the real SNI and other private fields, encrypts it under the public key, and wraps it in an "outer" ClientHello that uses a generic public-facing hostname.
4. The network observer sees only the outer ClientHello with the generic hostname. The real destination is hidden.
5. The server (which holds the private key) decrypts the inner ClientHello, sees the real SNI, and continues the handshake normally.

The CDN multiplexing effect

ECH's privacy benefit is biggest when many sites share one server. On a major CDN, millions of sites sit behind a small pool of IPs. With plaintext SNI, the network sees IP + SNI and identifies the specific site. With ECH, the network sees only IP + generic outer SNI (e.g., "cloudflare-ech.com" or similar bucket name) and cannot distinguish among the millions of sites.

This is sometimes called "the anonymity set." A user on a CDN with ECH has an anonymity set equal to the number of sites on that CDN — millions. Without ECH, the anonymity set is one (the specific site).

Why ECH needs encrypted DNS

If your DNS queries are plaintext, an observer sees you query secret-site.example and immediately knows the destination — before TLS even starts. ECH's encryption of SNI accomplishes nothing if the DNS query happened in the clear. For ECH to deliver its privacy benefit, DNS resolution must also be private, which in practice means DoH or DoT to a resolver that isn't operated by the entity you're hiding from.

This is why browser ECH support is usually paired with browser DoH: the two are co-dependent privacy properties.

Deployment status

The practical effect for an end user: if you visit a site hosted on a major CDN with ECH enabled, and you're using a modern browser with DoH and ECH on, the hostname is encrypted. If any of those pieces is missing, SNI falls back to plaintext.

What ECH does not hide

• Destination IP. Packets must route to a specific IP. This is unavoidable at the IP layer.
• Traffic timing and size. Even with ECH, an observer can analyze the pattern of bytes.
• Anything past the network layer. ECH is purely a network-eavesdropper protection. The server itself sees everything as before.
• Identity through other channels. Cookies, fingerprints, login state — all unaffected by ECH.

ECH and middleboxes

Some networks (corporate, government, or ISP) deploy middleboxes that inspect plaintext SNI to enforce filtering or content categorization policies. ECH makes that inspection impossible at the SNI level. The middlebox can still see IP and traffic patterns, and can still block by IP, but it cannot make decisions based on the specific hostname inside an encrypted-SNI connection.

This has produced friction with some network operators who depend on SNI-based filtering for content policy or compliance. The IETF design includes the possibility for clients to fall back to plaintext SNI in environments that explicitly require it, but that fallback is controlled by the client, not by the middlebox.

Verifying ECH is active

1. Use a modern browser that supports ECH (recent Firefox or Chrome).
2. Enable DoH in browser settings (or system-wide).
3. Visit a site hosted on an ECH-supporting CDN.
4. Open developer tools or a network inspector; look for the ECH indicator the browser exposes (varies by browser).
5. Alternatively, several public test pages confirm whether your browser successfully negotiated ECH on a controlled connection.

Frequently Asked Questions

What is ECH?

Encrypted Client Hello is a TLS extension that encrypts the entire ClientHello message — including the SNI hostname — so that network observers cannot see which site a client is connecting to. It replaces the earlier ESNI (Encrypted SNI) draft and is being standardized by the IETF.

What is SNI and why does it need encryption?

Server Name Indication is the TLS extension where the client tells the server which hostname it wants to talk to. It is sent in plaintext in the ClientHello because the server has to read it before completing the TLS handshake (to select the right certificate). The plaintext SNI is the single biggest hostname leak in HTTPS — anyone on the network path can read it. ECH encrypts it under a public key the server publishes in DNS.

Why isn't ECH deployed everywhere yet?

ECH requires three pieces in alignment: the client (browser) must support ECH; the server must support ECH and publish its public key via an HTTPS DNS resource record; and the resolver path used to fetch that DNS record must itself be private (DoH or DoT). Without all three, ECH falls back to plaintext SNI. Adoption is growing — major CDNs and browsers have support — but the deployment is gradual.

Does ECH require DNS over HTTPS?

Effectively yes. ECH's public key is fetched from DNS. If the DNS query is plaintext, an observer sees the query for the hostname and can deduce the destination even before the TLS handshake hides SNI. To get the privacy benefit, DNS resolution must also be encrypted (DoH or DoT to a resolver that isn't your ISP).

What does ECH hide?

ECH hides the SNI hostname from network observers. It does NOT hide the destination IP — packets still route to a specific IP. The privacy benefit is strongest when many hostnames share the same IP (typical for CDNs): the network sees "connection to a CDN IP" but cannot distinguish which of the millions of sites on that CDN was visited.