ECH (Encrypted Client Hello)

Encrypted Client Hello is standardized in RFC 9849, published in March 2026. The client builds two ClientHellos: an inner one containing the real SNI, the ALPN list and other private extensions, encrypted with HPKE under the server's ECH public key, and an outer one that carries only the public name of the client-facing server. The client-facing server decrypts the inner ClientHello and continues the handshake with it.

Why it matters

SNI is plaintext even in TLS 1.3, so anyone on the path can see which hostname a client requests. ECH closes that gap when many sites sit behind one provider, because observers see only the shared public name. The ECH configuration is usually published in the ech parameter of a DNS HTTPS record, and browsers generally fetch it over encrypted DNS, since a plaintext DNS lookup would reveal the name anyway. ECH also defines a retry path: if the server cannot decrypt the inner ClientHello, it completes the handshake on the outer one and returns fresh configurations, so stale DNS data does not permanently break connections. For enterprise networks, ECH means policies that classify traffic by SNI stop seeing the real hostname.

Example

dig +short HTTPS example.com
# 1 . alpn="h3,h2" ech=<base64-encoded ECHConfigList>

If such a record exists and the browser supports ECH, a packet capture shows only the provider's public name in the outer ClientHello.

Common misconceptions

• ECH makes the visited site invisible. The destination IP, unencrypted DNS queries and traffic patterns can still reveal a lot; ECH mainly hides the hostname when many sites share one front end.
• ECH is just ESNI renamed. ESNI encrypted only the SNI extension and never became an RFC; ECH encrypts the whole inner ClientHello.
• Any server can enable ECH with one setting. It needs TLS 1.3, an ECH key pair, DNS publication and key rotation, so it is mostly deployed by CDNs and large operators.