How to Configure Encrypted Client Hello (ECH) in Google Chrome

Even when browsing over Transport Layer Security (TLS 1.3), traditional web connections transmit the destination hostname in plaintext inside the Server Name Indication (SNI) header during the initial handshake. This enables network eavesdroppers, Internet Service Providers (ISPs), and local network firewalls to monitor visited websites without breaking encryption. Encrypted Client Hello (ECH)—an evolution of Encrypted SNI (ESNI)—resolves this vulnerability by encrypting the entire ClientHello payload using public keys distributed via DNS over HTTPS (DoH). In Google Chrome, enabling and auditing ECH guarantees complete metadata privacy.

Understanding Encrypted Client Hello Architecture

ECH secures the cryptographic handshake through dual ClientHello structures:

• Outer ClientHello (Plaintext): Contains a generic, shared public-facing domain name (the "public name"), such as Cloudflare or Fastly CDN frontend gateways. Network observers see only this generic CDN destination.
• Inner ClientHello (Encrypted): Contains the actual target domain (the private SNI, e.g., digitash.com), sensitive application parameters, and extensions. Encrypted using the server’s public key.
• DNS HTTPS Resource Records (SVCB/HTTPS): The browser queries the authoritative DNS server via encrypted DNS (DoH) for Type 65 HTTPS records, extracting the server’s ECH public encryption keys before initiating connection handshakes.

Configuring DNS over HTTPS (DoH) in Google Chrome

Because ECH requires secure DNS key retrieval to avoid plaintext DNS interception, DoH must be active:

1. Open Google Chrome, click the three-dot menu, and select Settings.
2. Navigate to Privacy and security > Security.
3. Scroll down to the Advanced section and locate Use secure DNS.
4. Ensure the toggle is enabled and select With: Cloudflare (1.1.1.1) or Google (Public DNS) from the provider menu.

Enabling ECH Flags via chrome://flags

While Chrome enables ECH progressively for supported endpoints, you can enforce strict ECH capabilities via experimental flags:

1. Type chrome://flags into the address bar and press Enter.
2. Search for Encrypted Client Hello:
   • Locate the flag labelled #encrypted-client-hello and change it to Enabled.
3. Search for Use DNS https ALPN:
   • Ensure #use-dns-https-svcb-alpn is set to Enabled, allowing Chrome to resolve HTTPS resource records containing ECH configs.
4. Click the blue Relaunch button to restart the browser.

Testing and Verifying Active ECH in Chrome DevTools

Verify whether your browser successfully establishes ECH-encrypted handshakes:

1. Navigate to Cloudflare’s verification endpoint: https://cloudflare.com/ssl/encrypted-sni/.
2. Click Check My Browser: verify that Secure DNS, DNSSEC, TLS 1.3, and Encrypted Client Hello report successful green checkmarks.
3. Open Chrome DevTools by pressing Ctrl + Shift + I (or Option + Command + I on macOS).
4. Switch to the Security panel:
   • Inspect the active connection parameters: verify that the TLS connection reports ECH: true alongside TLS 1.3 and modern AEAD cipher suites.

Troubleshooting ECH Downgrade and Fallbacks

If ECH fails to negotiate:

• DNS Key Staleness: If the origin server rotates its private key, Chrome automatically renegotiates using the fallback public name, retrieves the fresh ECHConfig retry token, and re-establishes encrypted communication seamlessly.
• Local Intercepting Firewalls: Corporate deep packet inspection (DPI) firewalls that strip SVCB DNS records will force Chrome to fall back to standard unencrypted SNI unless strict DoH policies are enforced.