Encrypted Client Hello explained

Encrypted Client Hello, or ECH, is a TLS 1.3 feature that encrypts the part of the handshake that traditionally revealed which website a visitor was connecting to. For decades the Server Name Indication, or SNI, in the TLS ClientHello was sent in plaintext, letting anyone watching the network see the hostname even though the web traffic itself was encrypted. ECH encrypts the ClientHello, including the SNI, so a passive observer can no longer read the destination hostname directly.

The problem it solves

TLS protects the data after the handshake, but the ClientHello itself is sent in the clear. That single message carries the SNI, which a privacy-conscious user may not want a network observer to see, and it also carries the list of supported protocols and key shares, revealing implementation details. A censor or middlebox can read the SNI and block, throttle, or log visits to a hostname by name.

ECH fixes the leak by encrypting the ClientHello under a public key that the destination publishes. An on-path observer still sees a TLS handshake, but the plaintext hostname is hidden, and the effective visibility is reduced to the service provider rather than the exact server. ECH is standardised in RFC 9849, published in March 2026, and builds on earlier work that encrypted SNI.

How it works

For a client to use ECH, the destination must publish a set of ECH configuration keys, typically in a DNS HTTPS or SVCB record. The client fetches those keys, encrypts its ClientHello to the chosen key, and that encrypted ClientHello is presented to the server during the handshake. The server, which holds the matching private key, decrypts it and completes the connection.

Because the key is delivered through DNS, ECH is closely tied to secure DNS. In practice a client can only encrypt its ClientHello if it can first retrieve the ECH keys, so the feature is most often seen alongside DNS over HTTPS or DNS over TLS, and browsers tend to enable ECH when a site publishes the required records. Even when the keys are fetched over ordinary DNS, some ECH is still considered better than none, though the strongest privacy configuration retrieves the keys over encrypted DNS.

Support has matured: Chrome has had ECH enabled by default for users with secure DNS, and the feature graduated from an experimental flag to default behaviour, alongside standardisation and support in the OpenSSL library between major versions. A site does not need to do anything special for a browser merely to attempt ECH, since a client that cannot complete encrypted client hello simply falls back to a normal handshake.

What it changes

For a website operator, the practical effects are limited. ECH is most noticeable when a site sits behind a shared host where the SNI was previously used to pick the right certificate, because a true proxy may need to see the server name or the configured ECH key to maintain that routing. In most modern setups the server or CDN handles the keys and the hostname routing automatically, and the certificate and site continue to work unchanged.

For privacy, ECH narrows what a passive observer learns: it can still see that a client is talking to a particular service provider, but not which server in that provider's set terminates the connection. ECH is layered on top of TLS 1.3, so it only applies where TLS 1.3 is negotiated. It does not encrypt DNS by itself, which is why the strongest overall configuration combines ECH with encrypted DNS for both handshake and lookup.

If ECH or the HTTPS records behind it are not configured, little about the visible behaviour changes: clients just use the plaintext SNI as before. The cost is only that the destination hostname stays readable on the wire. See TLS 1.3 handshake and how the SSL handshake works for the surrounding protocol, and DNS over HTTPS for the encrypted lookup ECH depends on to fetch its keys.