Encrypted Client Hello (ECH): How It Works and How to Enable It

How ECH hides the hostname from passive network observers, why it requires HTTPS DNS records, and how to enable and verify it.

The problem: SNI leaks the hostname

When a TLS connection begins, the client sends a ClientHello message that includes the Server Name Indication (SNI) -- the hostname the client wants to connect to. SNI is necessary because a single IP address often hosts many domains, and the server needs to know which certificate to present before the encrypted channel is established.

The problem is that the ClientHello is sent in plaintext. Anyone observing the network -- an ISP, a corporate firewall, a coffee shop attacker, or a nation-state surveillance system -- can see exactly which hostname the client is connecting to, even though TLS encrypts all subsequent traffic. This metadata leakage undermines the privacy that HTTPS is supposed to provide.

HTTPS encrypts what you send and receive, but without ECH, it does not hide where you are going. The destination hostname is visible in every TLS connection to every passive observer on the network path.

What ECH does

Encrypted Client Hello (ECH) encrypts the SNI and other sensitive fields in the ClientHello message, so that passive observers see only an "outer" ClientHello directed at a generic, privacy-preserving name (the public name), while the real hostname is encrypted inside the message and only readable by the server.

ECH splits the ClientHello into two layers:

Outer ClientHello -- visible to the network. Contains the public name (typically the CDN or hosting provider's name, e.g., cloudflare-ech.com). This is what an observer sees.
Inner ClientHello -- encrypted with a public key obtained from DNS. Contains the real hostname the client wants to reach. Only the server can decrypt it.

The result: a passive observer sees the client connecting to the CDN's generic name, not the specific website. The actual destination is hidden inside the encrypted inner ClientHello.

How ECH works

ECH relies on three components working together:

HTTPS DNS record -- the domain publishes an HTTPS (type 65) DNS record containing an ech parameter. This parameter holds the server's ECH public key (an HPKE key) that clients use to encrypt the inner ClientHello.
Client support -- the browser or TLS client fetches the HTTPS record, extracts the ECH configuration, and uses the public key to encrypt the inner ClientHello before connecting.
Server support -- the server (or CDN edge) holds the corresponding private key, decrypts the inner ClientHello, reads the real SNI, and serves the appropriate certificate and content.

The DNS lookup for the HTTPS record should itself be encrypted (via DNS-over-HTTPS or DNS-over-TLS) to prevent the hostname from leaking at the DNS layer. Without encrypted DNS, an observer can still see the DNS query even though the TLS SNI is hidden.

The HTTPS DNS record

The HTTPS record (RFC 9460) is a DNS record type that advertises HTTPS service parameters. For ECH, the critical parameter is the ech value, which contains the Base64-encoded ECHConfig structure:

example.com.  300  IN  HTTPS  1 . alpn="h2,h3" ech="AEX+..."

The ECHConfig includes:

The public name (what appears in the outer ClientHello)
The HPKE public key (for encrypting the inner ClientHello)
The supported HPKE cipher suites
The maximum name length (to prevent length-based traffic analysis)

Without this DNS record, clients have no way to obtain the ECH key, and ECH is not available. This is why the lens check flags domains that do not advertise ECH in their HTTPS record.

Who supports ECH today

ECH is still in its early deployment phase. As of 2025:

Cloudflare -- enables ECH by default for all proxied domains. Cloudflare was the first major CDN to deploy ECH at scale. If your domain is proxied through Cloudflare, ECH is likely already active.
Firefox -- supports ECH by default (enabled since Firefox 118). Firefox uses DNS-over-HTTPS by default in many regions, providing the encrypted DNS layer ECH needs.
Chrome -- supports ECH (enabled in Chrome 117+). Requires the system or configured DNS resolver to support DNS-over-HTTPS.
Safari -- does not yet support ECH as of early 2025.
Self-hosted servers -- limited support. Some reverse proxies and TLS libraries are adding ECH, but it requires careful key management and DNS coordination.

How to enable ECH

The path to enabling ECH depends on your hosting setup:

Behind a CDN (Cloudflare, etc.)

If your domain is proxied through Cloudflare, ECH is typically enabled automatically. Verify by checking for the HTTPS DNS record with an ech parameter. If the record is present and contains an ECH configuration, ECH is active.

Self-hosted

Self-hosting ECH is more involved:

Generate an HPKE key pair for ECH.
Configure your TLS server to use the ECH private key and public name.
Publish the ECHConfig in an HTTPS DNS record for your domain.
Implement key rotation -- ECH keys should be rotated regularly, and the DNS record updated to advertise the new key while still accepting the old one during the transition.

This is complex because the DNS record and the server configuration must be kept in sync. A stale ECH key in DNS causes clients to encrypt the inner ClientHello with a key the server cannot decrypt, resulting in a fallback to non-ECH mode or a connection failure, depending on the client's retry behavior.

ECH and privacy: what it protects and what it does not

ECH addresses one specific privacy gap: hiding the hostname from passive network observers during the TLS handshake. It does not provide:

IP address privacy -- the server's IP address is still visible. For domains with dedicated IPs, the IP itself reveals the destination. ECH is most effective when the server IP is shared by many domains (CDN deployments).
DNS query privacy -- unless DNS is also encrypted (DoH/DoT), the DNS query for the domain is visible. ECH without encrypted DNS is a partial measure.
Traffic analysis resistance -- the size and timing of encrypted traffic can still reveal information about the content being accessed.
Protection from the server -- ECH protects the hostname from the network, not from the server itself. The server sees everything.

ECH is one layer in a defense-in-depth approach to connection privacy. It complements HTTPS, encrypted DNS, and HSTS, but does not replace any of them.

Verifying ECH

To check whether a domain supports ECH:

Check for the HTTPS DNS record: query the domain's HTTPS record and look for the ech parameter. If absent, ECH is not advertised.
Test with a supporting browser: Firefox and Chrome display ECH status in their developer tools (Security tab). A successful ECH negotiation shows "Encrypted Client Hello: true" or similar.
Use the DNS inspector: query for the HTTPS record type to see the raw ECHConfig data.

# Check for HTTPS record with dig
dig example.com HTTPS +short

# Expected output includes ech= parameter
# 1 . alpn="h2,h3" ech="AEX+DQA..."

Common issues

No HTTPS DNS record -- ECH requires a published ECHConfig in DNS. Without the HTTPS record, clients have no key to encrypt with. This is the most common reason ECH is not active.
Stale ECH key -- if the server rotates its ECH key but the DNS record still advertises the old key, clients encrypt with the wrong key. Robust implementations fall back to non-ECH mode, but the privacy benefit is lost.
DNS not encrypted -- ECH hides the hostname in TLS, but if the DNS query is in plaintext, the hostname leaks there instead. For ECH to be effective, DNS resolution must also be encrypted (DoH or DoT).
Split-horizon DNS -- corporate networks that intercept DNS queries may strip HTTPS records or return different results, effectively disabling ECH for their users.
Firewall interference -- some network middleboxes block or modify ClientHello messages with ECH extensions, causing connection failures. ECH includes a retry mechanism, but persistent interference degrades the user experience.

Encrypted Client Hello (ECH)