What is Encrypted Client Hello

Encrypted Client Hello (ECH) encrypts the server name during a TLS handshake so network observers cannot see which website you are connecting to. It closes the last major metadata leak in encrypted web traffic.

What was the problem?

When a client connects to a server using TLS, the very first message — the Client Hello — includes the Server Name Indication (SNI) field in plaintext. This tells the server which domain the client wants (necessary when multiple sites share one IP address). But because it's unencrypted, anyone on the network path — your ISP, a corporate firewall, a government — can see exactly which website you're visiting, even though the rest of the connection is encrypted.

This is like sealing a letter in an envelope but writing the recipient's name on the outside.

How does ECH fix it?

ECH encrypts the entire Client Hello using a public key that the server publishes in its DNS records. The client fetches this key (ideally via DNS-over-HTTPS to prevent DNS snooping), encrypts the real Client Hello inside an "inner" encrypted envelope, and wraps it in an "outer" Client Hello that contains a generic, non-identifying server name.

The server decrypts the inner Client Hello to learn the actual target domain. Network observers see only the outer Client Hello with its generic name.

What is the deployment status?

RFC 9849 standardized ECH in 2026. Cloudflare and major CDN providers support it. Chrome and Firefox have implementations. The main blocker is that ECH requires DNS-over-HTTPS to prevent an observer from simply reading the DNS query to learn the target domain — encrypting SNI is pointless if DNS lookups are still plaintext.

Why it matters

ECH is the final piece of the encrypted web. TLS encrypts content. DNS-over-HTTPS encrypts domain lookups. ECH encrypts the server name in the handshake. Together, they make it cryptographically infeasible for a passive network observer to determine which specific website a user is visiting.