What actually does Encrypted Client Hello encrypt, and which metadata still leaks?

What actually does Encrypted Client Hello encrypt, and which metadata still leaks?

A precise question, because ECH is often oversold as making TLS "fully private." It closes one specific gap.

For years, the last plaintext identifier in an HTTPS handshake was the Server Name Indication (SNI, RFC 6066): the hostname the client puts in the clear so a server hosting many sites knows which certificate to present. A network observer reading SNI learns exactly which site you're visiting, even though the rest is encrypted.

Encrypted Client Hello (ECH, the draft successor to ESNI) encrypts the sensitive ClientHello — including SNI and ALPN — under a public key the client fetches via DNS in an HTTPS resource record (the ech field of the SVCB/HTTPS RR, RFC 9460). The client sends an "outer" ClientHello naming a shared, generic public server, with the real "inner" ClientHello encrypted via HPKE (Hybrid Public Key Encryption, RFC 9180). The fronting provider decrypts and routes internally.

What still leaks: the destination IP address, and the DNS lookup itself unless it runs over DNS-over-HTTPS or DNS-over-TLS. ECH's privacy therefore depends on many sites sharing one front (a large anonymity set) and on encrypted DNS — without both, traffic analysis can still narrow the target.

Further reading: draft-ietf-tls-esni (ECH), RFC 9180 (HPKE), RFC 9460 (SVCB/HTTPS RR).

Bottom line: ECH hides SNI and ALPN via HPKE, but the destination IP and unencrypted DNS still leak — it needs a big shared front and encrypted DNS to actually anonymize.