Encrypted Client Hello or living with plaintext SNI: what does ECH actually hide?

Encrypted Client Hello or living with plaintext SNI: what does ECH actually hide?

What is the last plaintext leak in an otherwise-encrypted TLS 1.3 handshake, and is the fix ready to deploy? The leak is SNI; the fix is ECH, and the comparison is between an available privacy gap and an emerging closure.

Server Name Indication (SNI, RFC 6066) is sent in the clear in the ClientHello so the server knows which certificate to present. That means a network observer learns exactly which hostname you are visiting even though everything else is encrypted — the basis of much hostname-level filtering and surveillance.

ECH (Encrypted Client Hello, an IETF draft now widely implemented) encrypts the inner ClientHello, including SNI, under a public key the client fetches via DNS (an HTTPS resource record). The observer sees only a generic outer name. The dependency chain is the catch: ECH needs DNS-delivered keys, DNSSEC or encrypted DNS to protect that lookup, and provider support on both ends.

— Deploy ECH where your CDN and resolver support it to close the SNI leak.
— Recognize it is incomplete without encrypted DNS for the key fetch.
— Treat plaintext SNI as a known, unavoidable leak until ECH is end-to-end.

Further reading: RFC 6066 §3; the TLS ECH draft; RFC 9460 on HTTPS records.

Bottom line: SNI is the residual plaintext leak; ECH closes it but only when DNS delivery and encrypted resolution are also in place.