Encrypted Client Hello explained: what the SNI leaks and how ECH helps

In TLS 1.3 the handshake is mostly encrypted, but the Server Name Indication, which says which site you want, is sent in plaintext. Encrypted Client Hello, published as RFC 9849, encrypts it. It improves privacy only when DNS lookups are also protected and many sites share the same setup.

What SNI leaks

A network observer cannot read page content over TLS, but can usually see the server name in the ClientHello. That reveals which domain a person is visiting. According to the RFC, ALPN values are also exposed. This matters when one IP address hosts many sites and the name is the only clue to which one.

How ECH works

1. The client builds a private inner hello with the real server name and other sensitive fields.
2. It encrypts that inner hello with the server's public key using HPKE.
3. It wraps the result in an outer hello that carries harmless values, such as a public name for the hosting provider.
4. The client facing server either decrypts the inner hello and passes it to the backend, or ignores it and completes the handshake using the outer hello.

If the server rejects ECH, perhaps because the client had stale keys, it can send retry configurations so the client can try again. Clients without a valid configuration can send placeholder ECH extensions so ECH traffic does not stand out.

Servers publish their ECH configuration, including the public key and public name, usually in DNS HTTPS records, though it can also be delivered other ways.

Limits

The RFC lists several:

• Anonymity set. Privacy depends on many servers sharing the same configuration and behaving alike. A unique setup is easier to identify.
• Other leaks. Plaintext DNS queries, visible server IP addresses and non-ECH traffic can still reveal the destination.
• DNS trust. Configurations fetched from DNS are not authenticated by default, so an attacker who can tamper with DNS may strip ECH or supply fake keys. Encrypted DNS and DNSSEC help. See DoH vs DoT vs DNSSEC.
• Deployment friction. Servers that route on SNI, such as load balancers, may need changes. Middleboxes can cause failures.
• Scope. It applies to TLS 1.3, DTLS 1.3 and later.

What it means if you run a network

Filters that rely on reading the SNI lose that signal for ECH connections. Plan for controls that do not depend on it, such as endpoint policy, DNS controls you operate, or proxying with explicit consent. Do not try to block ECH blindly without testing, since the RFC notes middleboxes and misconfiguration can cause failures.

What it means if you run a site

Check whether your CDN or hosting provider supports ECH and whether you control the setting. If you terminate TLS yourself, check your TLS library and load balancer for support. RFC 9325 said ECH would likely be recommended in a future version once standardized, which this RFC now is.

Quick check

Sources

• RFC 9849, TLS Encrypted Client Hello
• RFC 9325

Last reviewed: 19 October 2026.