TLS Encrypted ClientHello (ECH) and SNI Privacy

Updated on Oct 8, 2026

10 min read

When a browser opens an HTTPS connection, encryption protects the page contents, but the initial connection setup can still reveal the requested hostname. TLS Encrypted ClientHello (ECH) is a protocol extension that encrypts sensitive parts of this handshake, including the real Server Name Indication (SNI). This explainer is for network operators, developers, and privacy-conscious users who need to understand what ECH protects, how a client finds the keys, and why encrypted DNS and server configuration both matter.

What Is TLS Encrypted ClientHello?

The TLS ClientHello is the first message a client sends when negotiating a secure connection. It proposes protocol settings and identifies the server name it wants to reach. SNI lets a server hosting many websites on one IP address select the correct certificate and site before the encrypted session is established. Without ECH, an observer on the network path can commonly read that hostname even though the later HTTPS traffic is encrypted.

ECH lets a capable client encrypt an inner ClientHello using a public key published by the destination service. It sends an outer ClientHello that can be processed by a server or shared front end without disclosing the inner hostname. The server that holds the matching private key decrypts the inner message and continues the TLS handshake for the intended site. The IETF ECH specification, RFC 9849, defines the protocol and its configuration and retry behavior.

ECH protects the hostname only when the client and server successfully negotiate it. It is not a replacement for HTTPS: the negotiated TLS connection still authenticates the server and encrypts application data. It is also separate from encrypted DNS. For that distinction, see how DNS over HTTPS and DNS over TLS protect resolver traffic.

The Problem ECH Solves

Traditional TLS encrypts application data after the handshake, but SNI has historically appeared in the ClientHello before encryption is established. An internet provider, Wi-Fi operator, or other on-path observer could use it to classify connections by hostname, even without reading the page or query parameters. The destination IP address and traffic patterns may offer additional clues.

This exposure is especially relevant when many unrelated sites share a CDN or hosting address: the IP alone may not identify the site, while SNI does. ECH moves the real hostname into encrypted handshake data. The outer ClientHello still gives the network and shared front end enough information to route or process the connection, but its public name is not necessarily the site the user intends to visit.

ECH narrows one source of metadata; it does not make a connection anonymous. DNS lookups, destination addresses, connection timing, and the resolver receiving a query can still disclose information. Encrypted DNS protects the client-to-resolver link, while ECH protects selected TLS handshake fields. They complement one another rather than providing the same protection.

How ECH Works

The client needs an ECH configuration containing a public key and the public name to use in the outer ClientHello. A service can publish this information in an HTTPS DNS record. HTTPS records are a DNS service-binding record type defined alongside SVCB by RFC 9460; one of their parameters can carry the ECH configuration.

At a high level, a connection proceeds as follows:

The client resolves the service and receives an HTTPS record with a usable ECH configuration.
It constructs an inner ClientHello containing the real SNI and other protected handshake parameters.
Using the configuration’s public key, it encrypts that inner message and sends an outer ClientHello addressed with the published public name.
The service’s ECH-capable front end decrypts the inner ClientHello and routes the connection to the intended site.
The client and server finish the TLS handshake; application data is then protected by the negotiated session.

The public name is a routing and cover identity, not the encrypted name. A hosting provider can operate a front end that accepts the public name and routes decrypted connections to sites behind it. The private key must be available to the endpoint that decrypts ECH, while the client only needs the published configuration and public key.

Connection property	TLS without ECH	TLS with ECH successfully negotiated
Real SNI in the initial handshake	Visible in the ClientHello	Carried inside the encrypted inner ClientHello
Outer handshake destination name	Usually the requested hostname	A configured public name
HTTPS page contents	Encrypted after the TLS handshake	Encrypted after the TLS handshake
DNS lookup visibility	Depends on resolver and DNS transport	Still depends on resolver and DNS transport
Destination IP and traffic timing	Observable to network observers	Still observable to network observers
Deployment requirement	Compatible TLS server and client	Client support, discoverable ECH configuration, and a correctly configured ECH-capable endpoint

ECH does not encrypt every field in every packet. The outer ClientHello remains visible, and TLS record sizes and timing can still reveal patterns. The protection also depends on the service not placing the real hostname in its public name or other exposed metadata.

Components and Key Concepts

Inner and outer ClientHello: The inner message contains the client’s actual connection parameters, including the real SNI. The outer message is what an on-path observer and the initial front end see. ECH encrypts the inner message; it does not hide the fact that a TLS connection is being established.

ECHConfig: This is the public configuration clients use to build an encrypted ClientHello. It identifies the public name and cryptographic parameters. Services must rotate keys and publish configurations in a way that allows DNS caches and clients to transition safely.

HTTPS DNS record: A client can discover ECHConfig using the ech parameter in an HTTPS record. The record is separate from the ordinary address records used to find an IP. A resolver that strips, mishandles, or serves stale HTTPS records can prevent a client from obtaining a usable configuration. The Linux DNS configuration guide covers how resolvers and DNS records fit into name resolution.

ECH-capable front end: A CDN, reverse proxy, or server must possess the matching private key and know how to route the decrypted request. A DNS record by itself does not enable ECH at the service. The Cloudflare ECH documentation describes one provider’s deployment controls and prerequisites.

Client support and retry behavior: Browsers and TLS libraries need ECH support and a valid configuration. If a server rejects a configuration, the protocol provides a way to supply retry configurations. Operational behavior depends on the client and service: administrators should verify whether retries preserve ECH and what happens when no valid configuration can be used instead of assuming every failure is private.

Real-World Use Cases

CDN-hosted websites: A shared edge service can terminate ECH for many customer hostnames, reducing exposure of individual site names on the path to the edge.
Privacy-sensitive browsing: A browser can conceal the intended hostname from local network observers when the resolver, client, and destination all support the required behavior.
Managed networks: Operators can reduce passive hostname disclosure while continuing to enforce policy at endpoints, resolvers, and application layers they control.
TLS and QUIC services: ECH applies to TLS handshakes, including TLS used by HTTP/3 over QUIC. It does not replace QUIC’s transport security; it changes what hostname information is exposed during TLS setup. See the QUIC and HTTP/3 overview.

Getting Started: Check ECH Discovery and Deployment

ECH is not a switch that can be enabled solely in a local DNS resolver. A service operator must enable it at a compatible TLS endpoint and publish the corresponding configuration. A client must support ECH and successfully retrieve that configuration.

On Debian or Ubuntu, install dig if it is not already available:

sudo apt install dnsutils

Query the HTTPS record for a hostname:

dig HTTPS www.example.com +short

Inspect the response for an ech parameter. Its presence shows that the DNS response advertises ECH configuration, not that a particular client negotiated ECH or that the endpoint can successfully decrypt it. Compare results from the recursive resolver used by clients with the service’s authoritative DNS data if the parameter is missing or stale. Remember that this diagnostic query is not itself encrypted unless the tool and resolver are configured for an encrypted transport.

For an operator, a practical validation sequence is:

Enable ECH on the TLS-terminating CDN or server and confirm it has the active private key and a valid certificate for the inner hostname.
Publish the provider-generated HTTPS record data without altering its ECH parameter.
Query the record through both authoritative DNS and the recursive resolvers used by clients; check for missing, stale, or filtered HTTPS records.
Test with a browser or TLS client that explicitly supports ECH. Use its network diagnostics and the service provider’s ECH telemetry to confirm acceptance; a generic TLS test may not offer ECH.
Repeat after configuration rotation and with cold and warm DNS caches. Observe rejection, retry, and fallback behavior to ensure failures do not silently expose the hostname contrary to policy.

Common failures include outdated DNS caches, resolver filtering of HTTPS records, a key mismatch between DNS and the TLS endpoint, unsupported client software, and middleboxes that interfere with unfamiliar handshake extensions. A packet capture can help identify whether a client sent an ECH extension, but presence alone does not prove the server accepted ECH; clients can also send a GREASE value that resembles an ECH attempt. Use endpoint-side telemetry or client diagnostics to confirm successful negotiation. Do not use a successful HTTPS page load as proof that ECH was active.

Common Misconceptions

“ECH hides the entire connection.”

ECH protects selected ClientHello content, including the real SNI, when successfully negotiated. It does not hide the destination IP, connection timing, traffic volume, or the identity of the resolver that receives a DNS query. An observer may still infer activity from those signals.

“Encrypted DNS makes ECH unnecessary.”

DoH and DoT encrypt a DNS exchange between a client and its recursive resolver. The TLS handshake to the destination is a separate connection with its own metadata. Using encrypted DNS does not by itself encrypt SNI; ECH does not by itself encrypt DNS. Combining them can reduce exposure at both stages, but does not conceal all metadata.

“An HTTPS record proves the server is using ECH.”

The record only advertises configuration to clients. The client may lack support, be unable to retrieve the record, or fail to negotiate with the endpoint. Confirm successful acceptance using client or server diagnostics, and check failure behavior as well as the normal path.

“ECH removes the need for TLS or certificate validation.”

ECH protects handshake fields; it does not authenticate the intended website by itself. The client still needs to complete a valid TLS handshake and validate the certificate for the real hostname. ECH is an addition to TLS, not a substitute for it.

Compare DNS over HTTPS and DNS over TLS to understand encrypted DNS and resolver trust.
Follow the DNS lookup process to see how a client obtains records before connecting.
Learn how QUIC and HTTP/3 use TLS for modern web transport.

Changelog

2026-10-08: First published.