Encrypted Client Hello (ECH) Guide: RFC 9849

For years, enterprise web filters, firewalls and DLP tools identified encrypted destinations by reading the server name in the TLS ClientHello, and Encrypted Client Hello (ECH) removes that signal. ECH became a Proposed Standard as RFC 9849 in March 2026, with DNS bootstrapping in RFC 9848, and Chrome and Cloudflare already enable it by default where both ends support it. This guide explains how ECH works on the wire, what it does and does not hide, how server operators deploy it, how enterprises keep the visibility they are entitled to on managed devices, and how to detect and measure ECH on your network. It is for network security engineers, web platform teams and security architects. For the wider question of whether and where to decrypt traffic, see the TLS Inspection Guide; this page goes deeper on ECH itself.

Key takeaways

ECH hides the real server name, not the connection. The inner ClientHello carrying the true SNI and ALPN is encrypted with HPKE; observers see only a shared public name such as a CDN's, plus IP address, timing and size.
DNS is the control point. Clients learn ECH keys from the ech parameter in SVCB or HTTPS records (RFC 9848), so whoever controls DNS on a device largely controls whether ECH is used.
Full TLS-terminating proxies still work. RFC 9849 requires a terminating proxy to generate its own ClientHello, so ECH defeats passive SNI inspection, not active interception on managed devices.
Policy beats breakage. On managed browsers use the vendor policy (Chrome's EncryptedClientHelloEnabled) and managed resolvers rather than tampering with traffic; on unmanaged devices accept that SNI filtering is ending.
Presence of the extension proves little. Clients send GREASE ECH extensions when they have no configuration, so detection must distinguish real ECH from GREASE by context, not by the extension alone.

How ECH works

A TLS 1.3 ClientHello normally exposes the server name indication (SNI), the ALPN list and other extensions in plaintext. ECH splits the message in two:

ClientHelloInner: the real hello, with the true server name and ALPN. It is encrypted using Hybrid Public Key Encryption (HPKE) to a public key the server published.
ClientHelloOuter: a public hello with innocuous values and the public_name of the client-facing server as its SNI. The outer hello is authenticated as associated data, so it cannot be altered without breaking decryption.
ECHConfig: the structure carrying the public key, HPKE suite and public name. It is identified on the wire by a config_id.

The client-facing server decrypts the inner hello and either completes the handshake itself (shared mode) or forwards it to a separate backend server (split mode), which is how CDNs and large hosting platforms operate. If decryption fails, for example because the client used a stale key, the server completes a handshake for the public name and returns retry_configs; the client validates the certificate for the public name and retries with the new key. A client that offered ECH but did not get it accepted sends the ech_required alert rather than silently carrying on.

Protocol element	Value or location	Defender relevance
`encrypted_client_hello` extension	TLS extension code point 0xfe0d	Seen in ClientHello for real ECH and GREASE ECH
`ech_outer_extensions`	Code point 0xfd00	Lets inner hello reference large outer extensions such as post-quantum key shares
`ech_required`	TLS alert	Signals a client that expected ECH and did not get it
`ech` SvcParamKey	Key 5 in SVCB and HTTPS records, Base64 ECHConfigList	The DNS signal that ECH is available
`public_name`	Outer SNI	What SNI-based filters now see, typically a shared provider name such as `cloudflare-ech.com`
`config_id` and outer cipher suite	Plaintext in the ECH extension	Visible; can hint at the provider, not the site

What ECH hides and what it does not

Signal	Before ECH (TLS 1.3)	With ECH
Real server name (SNI)	Plaintext	Encrypted; only public name visible
ALPN and inner extensions	Plaintext	Encrypted
Server certificate	Already encrypted in TLS 1.3	Encrypted
Destination IP address	Visible	Visible; identifying where an IP hosts one site
DNS query for the site	Visible unless encrypted DNS	Still visible unless encrypted DNS is used
Traffic size and timing	Visible	Visible; RFC 9849 notes timing side channels

RFC 9849 is explicit that ECH is not sufficient on its own: plaintext DNS lookups or a server IP that hosts only one site still reveal the destination. Its privacy depends on the anonymity set: many names behind the same client-facing server with the same ECHConfig and consistent TLS behaviour. The RFC warns that a distinct ECHConfig per name reduces the set to one, and that very frequent key rotation also shrinks it. That is why ECH protection is strongest on large CDNs and weakest on single-site servers. For defenders, the same property means an ECH public name tells you which provider a user reached, but almost nothing about which of its customers.

The DNS dependency

RFC 9848 defines how clients obtain ECH keys from SVCB or HTTPS records (built on RFC 9460). Three requirements matter operationally:

No fallback when ECH is advertised: if every alternative endpoint in the record set carries ech, an ECH-capable client must use SVCB-reliant connection establishment and must not send a ClientHello until SVCB resolution completes. Silent fallback to plaintext SNI would defeat the purpose.
Every IP must be ready: publishers must ensure every address of the target either holds the matching private key or is authoritative for the public name, or connections fail.
Mixed record sets are a downgrade risk: some records with ech and some without lets an attacker strip ECH; RFC 9848 does not recommend it.

DNS records carry no authenticity by themselves. RFC 9849 recommends DNSSEC with client-side validation and encrypted DNS transports (DoH, DoT, DoQ) to stop local attackers injecting fake configurations or stripping real ones. For enterprises this cuts both ways: a device using an external encrypted resolver gets ECH and bypasses your DNS policy at the same time. See the Encrypted DNS Enterprise Guide and the DNSSEC Deployment Guide.

Deploying ECH as a server operator

Decide shared or split mode: CDN-fronted sites usually get ECH from the provider (Cloudflare, for example, enables it by default on Free zones and offers a dashboard toggle on others). Self-hosted operators need a TLS stack with ECH server support and a public name they control.
Choose a public name that maximises the anonymity set: one public name and one ECHConfig for as many hosted names as possible, with a valid certificate for the public name.
Publish HTTPS records with ech: sign the zone with DNSSEC, and make every address in the record set ECH-capable to avoid connection failures.
Rotate keys deliberately: keep old keys valid for at least the DNS TTL so clients with cached configurations still connect, and rely on retry_configs for the rest. Do not rotate so often that you shrink the anonymity set.
Keep TLS configuration consistent: the RFC warns that differing cipher suites or behaviour across names can identify a backend despite ECH.
Test and roll back: stage with a low TTL, monitor handshake failures and ech_required alerts, and remove the ech parameter from DNS to roll back.

Enterprise visibility: choosing an approach

An organisation's legitimate need is visibility on devices and networks it manages, under policy and law. ECH changes how that is achieved, not whether it is possible.

Approach	How it works	Trade-offs	Fits
Browser policy	Chrome `EncryptedClientHelloEnabled` set to false (supported on Chrome, ChromeOS and Android from version 105); equivalent controls in other managed browsers	Clean and auditable; only covers managed browsers; Chrome describes the policy as temporary	Managed fleets needing SNI-based filtering during transition
Managed DNS resolver	Force devices to enterprise resolvers; Cloudflare documents returning NOERROR with no answer or NXDOMAIN for HTTPS queries, and answering the Firefox canary domain `use-application-dns.net`	Covers browsers that rely on HTTPS records; editing records instead can break DNSSEC-validating clients; ineffective if devices use external DoH	Networks with control over device DNS
Full TLS interception proxy	Proxy terminates TLS and generates its own ClientHello upstream, as RFC 9849 requires	Works with ECH; carries all the costs and privacy obligations of decryption	Regulated environments already decrypting
Endpoint or browser-based controls	Agent or enterprise browser sees the URL before encryption	Independent of network protocol changes; requires managed endpoints	Hybrid and remote workforces
Accept reduced visibility	Filter by IP reputation, DNS logs and identity-aware access instead of SNI	Lower cost, less granular	Guest and BYOD networks

Decision guidance: small organisations without decryption should prefer managed DNS and browser policy and move web filtering to the endpoint over time. Large organisations with secure web gateways should confirm their proxy terminates TLS for in-scope categories (and so is unaffected), set browser policy consistently, and plan for SNI-based categorisation losing accuracy on bypassed traffic. Do not attempt to strip or block the ECH extension on the wire: RFC 9849 notes a proxy that is not authoritative for the public name cannot forge a disable signal, and interference produces failures, not visibility. See the Secure Web Gateway and Web Filtering Guide.

Workloads, egress allow lists and identity

ECH is not only a browser issue. Many cloud egress firewalls and service meshes allow outbound connections from workloads by matching the SNI against an allow list of API hostnames. That design assumes the SNI names the real destination. As TLS libraries used by services, agents and SDKs adopt ECH, an allow list entry for a CDN public name would effectively permit every site behind that provider, and a workload connecting to an ECH-enabled destination may be blocked or, worse, allowed for the wrong reason.

Prefer explicit egress proxies for workloads: route machine traffic through a forward proxy that terminates or at least resolves names itself, so policy is enforced on the name the workload asked for.
Control workload DNS: workloads should use cluster or VPC resolvers you log; a container that brings its own DoH client bypasses both DNS and SNI controls.
Never allow-list a shared public name: treat names such as a CDN's ECH public name as covering an unbounded set of destinations.
Tie egress to identity: authorise outbound access per workload identity (service account, SPIFFE ID, cloud role) rather than per host network rule, so a compromised workload cannot borrow another's allow list.
Watch AI agents and automation: agents that browse or call tools are high-volume, non-human clients of exactly the CDN-hosted services ECH protects. Give each its own identity and proxy path so its destinations remain auditable.

See the ZTNA Guide and the SASE and SSE Guide for identity-aware access models that do not depend on SNI.

Detection and measurement

Real ECH versus GREASE: GREASE ECH sends a dummy extension when the client has no configuration, so treat the extension as a weak signal. A ClientHello whose outer SNI is a known ECH public name and whose destination has an ech parameter in DNS is a stronger indicator.
DNS telemetry: log HTTPS (type 65) queries and responses containing ech on enterprise resolvers; this is the most reliable inventory of ECH use.
Resolver bypass: alert on DoH and DoT to external resolvers from managed devices, which defeats both DNS policy and ECH controls.
Threat use: malware command and control can hide behind shared public names in the same way domain fronting (ATT&CK T1090.004) abused CDNs; monitor for unusual volume to ECH public names from non-browser processes, which endpoint telemetry shows better than the network (T1071.001 Web Protocols, T1573 Encrypted Channel).

Metric	Why it matters
Share of outbound TLS sessions where SNI is an ECH public name	Shows how much SNI-based categorisation is now blind
Managed browsers with ECH policy in the intended state	Confirms policy coverage
Managed devices using non-enterprise DNS	Tracks the main bypass path
Handshake failures and `ech_required` alerts on your own services	Detects broken key rotation or DNS publishing
Web filtering decisions made at endpoint versus network	Measures progress away from SNI dependence

Framework mapping

Framework	Reference	Relevance
NIST SP 800-53 Rev. 5	SC-8 Transmission Confidentiality and Integrity	ECH extends confidentiality to handshake metadata on your own services
NIST SP 800-53 Rev. 5	SI-4(10) Visibility of Encrypted Communications	Deciding which encrypted traffic must be visible to monitoring
NIST SP 800-53 Rev. 5	SC-7 Boundary Protection	Web filtering and proxy architecture
NIST SP 800-53 Rev. 5	SC-20, SC-21 Secure Name/Address Resolution Service	DNSSEC and trusted resolvers for ECH key delivery
NIST CSF 2.0	PR.DS-02; DE.CM-01	Data in transit protection and network monitoring
MITRE ATT&CK	T1573 Encrypted Channel; T1090.004 Domain Fronting; T1071.001 Web Protocols	Adversary use of encrypted, shared-front channels

Common failure patterns

Discovering ECH from a broken filter: categorisation silently degrades as more traffic shows a CDN public name. Measure it before users notice.
Blocking the extension on the wire: causes handshake failures and support tickets without restoring visibility.
Editing HTTPS records in a validating environment: rewriting records instead of returning no answer can break DNSSEC validation, as Cloudflare warns.
Policy without DNS control: browser policy is set, but devices use an external DoH resolver and other applications use ECH anyway.
Server-side mixed record sets: some endpoints without keys cause intermittent failures or a downgrade path.
SNI allow lists for workloads: cloud egress rules that match a CDN public name quietly open access to every site behind it, and nobody notices because traffic keeps flowing.
Assuming ECH means anonymity: a single-site server's IP address still identifies the destination.

Practitioner checklist

Measure today what share of your outbound TLS shows an ECH public name as SNI.
Decide, document and apply the ECH browser policy for each managed browser.
Enforce enterprise resolvers on managed devices and alert on external DoH and DoT.
Confirm with your proxy vendor that TLS-terminated traffic is unaffected and which categories rely on SNI.
Move high-value web controls to endpoint or enterprise browser where possible.
For your own sites, publish ECH through HTTPS records with DNSSEC and a consistent TLS configuration.
Log HTTPS record queries carrying ech and keep them for investigations.
Review workload egress allow lists for shared public names and move machine egress behind an identity-aware proxy.
Review the policy each quarter: Chrome describes its ECH policy as temporary and controls will change.

Encrypted Client Hello Guide: How ECH Works and What It Breaks