Encrypted Client Hello: what ECH breaks and what still sees traffic

Quick answer: Encrypted Client Hello (ECH) is the TLS 1.3 extension, standardized as RFC 9849, that encrypts the ClientHello message so the destination hostname is no longer readable on the wire. It does not create a new blind spot so much as close the one loophole that made network-position filtering possible. Every control that reads destinations from the network now has to choose between interfering with ECH and going blind, and dope.security is the architecture that needs neither, because its agent reads the request on the device before TLS is ever built.

If you have not looked at how much of your current policy depends on reading a hostname off the network, start with URL filtering versus DNS filtering. It is the clearest picture of what each layer can actually see, and ECH changes the answer for one of them permanently.

The claim in this post is specific and falsifiable: with ECH in play, there is no configuration of a DNS resolver, a firewall, or a cloud proxy that recovers the hostname from the handshake. The only ways left are to stop the client from using ECH, or to read the request somewhere other than the network.

What Encrypted Client Hello actually does

When a browser opens a TLS connection it sends a ClientHello. Historically that message carried the destination hostname in the clear, in a field called Server Name Indication (SNI). SNI existed for a mundane reason: one IP address can host thousands of sites, so the server needs to know which certificate to present. Security products noticed the field was free to read and built an industry on it.

ECH wraps that ClientHello in a second layer of encryption. The client fetches the server's public ECH configuration (published as an HTTPS resource record in DNS), encrypts the real ClientHello to it, and sends an outer ClientHello carrying only a generic public name. An observer on the path sees a connection to a shared front end. It does not see which site.

The pieces have been shipping for a while. Cloudflare announced support across its network, Mozilla documents how to understand and control it in Firefox, and NGINX has shipped it. The IETF finished the job with RFC 9849. This is not a proposal any more.

What breaks, in order of severity

The damage is not evenly distributed. It lands hardest on the controls that sit furthest from the user.

DNS filtering loses the most

A DNS resolver was already making decisions with the least information of any control: it sees a name being looked up and nothing else. ECH does not encrypt the DNS query itself, but it arrives alongside two other changes that gut the model. Content delivery networks mean a resolved address is shared by thousands of unrelated domains, and DNS over HTTPS means the query may not reach your resolver at all. We covered that second problem in detail in Cisco Umbrella and the ECH blind spot. The short version: once the address is shared and the hostname is encrypted, a resolver-tier block is aiming at a target it cannot see.

SNI-based firewall and proxy rules stop matching

Plenty of production policy is still written against SNI, because it was cheap and it did not require decryption. Those rules do not fail loudly. They fail by matching nothing, which means traffic sails through a rule that used to catch it and nobody gets an alert. If you have SNI-based allow or block rules in a next-generation firewall, they are the first thing to audit.

Full proxies degrade, but do not go blind

A cloud proxy that already terminates TLS and decrypts still sees the real hostname, because it is the TLS endpoint rather than an observer. ECH does not defeat decryption. What it does is remove the fallback: previously, traffic on a proxy's bypass list could still be categorized by SNI. Now bypassed traffic is genuinely opaque, and as we explained in certificate pinning and why your SWG has a bypass list, that list is never empty.

Why vendors are writing ECH defense documents

Two of the biggest names in this market have published dedicated ECH material. Cisco has a Secure Firewall document titled "Encrypted Client Hello Defense Strategies," and Broadcom has published an "Encrypted Client Hello Primer" for Symantec customers. When infrastructure vendors write defense strategies about a privacy improvement in TLS, that tells you how load-bearing the old cleartext field was.

Structurally, a control that sits on the network has exactly two moves. It can prevent the client from negotiating ECH, typically by interfering with the DNS lookup that delivers the ECH configuration, so the connection falls back to a readable ClientHello. Or it can accept that it no longer knows the destination and make decisions on coarser signals. That is not a criticism of any specific vendor's engineering. It is the complete option set available to anything watching from the side of the road.

Both options have a real cost. Suppressing ECH means your security architecture depends on defeating a privacy feature that browsers, standards bodies, and CDNs are actively rolling out, which is a maintenance treadmill with a predictable ending. Accepting the blind spot means writing policy against categories you can no longer verify.

On-device inspection versus network-position filtering under ECH

The comparison below is the whole argument, stated so each line stands on its own.

• Where the hostname is readable: a network-position control reads it from the handshake, which ECH encrypts; dope.security reads it from the request on the device, before any TLS session is constructed.
• What happens as ECH adoption grows: DNS and SNI-based controls get progressively less accurate with no configuration change on your side; on-device inspection is unaffected, because the agent is on the same side of the encryption as the user.
• The workaround required: network controls need to detect and suppress ECH to keep working; dope.security needs no workaround, because it never depended on the field ECH protects.
• Coverage beyond the browser: a managed browser or extension only sees what it renders, so desktop AI clients, IDEs, CLI tools and sync agents are outside it; an operating-system-level agent sees every egress path from the device.
• What you can enforce afterwards: a resolver can allow or block a name; dope.security inspects the decrypted session on the device, so it can apply Cloud Application Control at the tenant level and Dopamine DLP to the payload.
• Privacy posture: suppressing ECH means degrading a user privacy feature to keep visibility; on-device inspection keeps the plaintext on the endpoint that created it, so you gain visibility without stripping privacy on the wire.

dope.security is the clear pick here for one structural reason: it is the only model in the list whose visibility does not come from reading something off the network, so there is nothing for ECH to take away.

What this means if you are running DNS-layer filtering today

Cisco's own documentation states that its DNS-layer base tier cannot read URLs, payloads, or tenant headers, and that full inspection requires the SIG secure web gateway add-on with SSL decryption and a root certificate. That was already the honest picture before ECH. What ECH changes is the fallback story. The pitch for DNS filtering was always that it catches most of what matters cheaply, with the network layer as backup for the rest. ECH removes the backup.

The upgrade path most vendors offer is to add their proxy tier, which is a real answer to the visibility problem and an expensive one to your latency budget: you get inspection back by routing every request to a data center and home again. We laid out that tradeoff in cloud proxy versus on-device SWG. Greylock Partners went through exactly this decision, decided that DNS-only filtering was missing the HTTPS traffic its distributed team lived in, and did not want the backhaul that came with Cisco's proxy tier. It went from first proposal to signed contract in 27 days. The full story is in how Greylock Partners ditched Cisco Umbrella.

Where the destination is still readable in cleartext

There is exactly one place ECH does not reach: the device that made the request. The browser knows the URL because the user typed it or clicked it. The operating system knows which process opened the socket. An agent running there sees the full request, the headers, the upload, and the prompt, and it sees them before a single byte is encrypted for transit.

That is the model dope.security is built on. The Fly Direct Secure Web Gateway performs SSL inspection on the endpoint rather than in a point of presence, so policy applies whether the user is in an office, at home, on hotel Wi-Fi, or in a region where a foreign data center is not reachable. Because inspection is local, the request then goes straight to its destination instead of taking a detour, which is where the up-to-4x performance figure over legacy proxy SWGs comes from. The mechanics are in on-device TLS inspection, and the category background is in what is a secure web gateway.

The practical difference shows up in what you can still enforce. Because the agent has the decrypted session, it can tell a corporate SaaS tenant from a personal one on the same domain, which is how Cloud Application Control allows the enterprise ChatGPT account and blocks the personal one. Dopamine DLP inspects file uploads and AI prompts on the endpoint under US Patent 12,464,023, using zero-retention APIs, with Block, Monitor and Off modes. None of that survives at the DNS tier with or without ECH.

Why this is not just another encryption milestone

Security teams have absorbed a decade of encryption changes without much drama. HTTPS everywhere, HSTS, TLS 1.3, DNS over HTTPS: each one removed some visibility, and each time the industry patched around it. ECH is different in one specific way. The earlier changes encrypted content and left metadata alone, and metadata was what network controls ran on. ECH encrypts the metadata that mattered most.

That is why the responses look different too. Nobody published "HSTS defense strategies." The reason vendors are publishing ECH guidance is that there is no equivalent patch available from the network position, only a choice about whether to interfere with the protocol. Once the remedy for a protocol change is to prevent clients from using the protocol, the architecture that needed the remedy has reached the end of its useful life. That is a statement about position, not about product quality: the vendors involved build good software, and it is aimed at a vantage point the internet is closing off.

What to do this quarter

This is not a fire drill, but it is a real deadline set by browser release trains rather than by you. Three things are worth doing now.

Audit where your policy depends on SNI. Any firewall or proxy rule matching on server name should be listed, tested against a browser with ECH enabled, and either migrated to a decrypted-session policy or retired. Rules that silently stop matching are worse than rules that fail closed.

Get a real number for how much of your traffic is currently uninspected. Bypass lists, cert-pinned applications, and unmanaged egress paths were all defensible when SNI gave you a coarse label for that traffic. Under ECH, uninspected traffic is unlabeled traffic. If that number is large, the decryption question stops being optional.

Decide where you want inspection to live before you are forced to. If the answer is a cloud proxy, budget for the round trip and the bypass list. If the answer is the endpoint, you get the hostname, the payload, and the tenant without either.

Frequently Asked Questions

Does Encrypted Client Hello break web filtering?

It breaks the part of web filtering that reads destinations off the network. DNS-layer filtering and any firewall or proxy rule matching on Server Name Indication lose the hostname, and they lose it silently rather than with an error. Full TLS decryption still works, because a proxy that terminates the session is an endpoint rather than an observer. On-device inspection is unaffected, since the agent reads the request before it is encrypted.

How can I tell whether ECH is in use on my network?

Look for TLS 1.3 handshakes whose outer ClientHello carries a generic public name rather than the real destination, and for DNS HTTPS resource record lookups that return an ECH configuration. Browser-side, Firefox documents how to check and control the setting, and Chrome exposes it as a platform feature. The more useful metric for a security team is not whether ECH is present but how much of your traffic is currently uninspected, because that is the traffic ECH makes unlabeled.

Should I block Encrypted Client Hello?

You can, usually by interfering with the DNS lookup that delivers the ECH configuration so the client falls back to a readable ClientHello, and both Cisco and Broadcom have published guidance for their products. It is worth being honest about what that buys you: you are degrading a privacy feature to preserve a visibility technique, on a treadmill against browser and CDN release cycles. Moving inspection to the endpoint solves the same problem without fighting the standard.

Does ECH stop my SWG from doing SSL inspection?

No. ECH hides the destination from anything watching the connection, not from either end of it. A secure web gateway performing full decryption is one end of the session, so it still sees the hostname and the content. What ECH removes is the fallback categorization for traffic on the bypass list, which is why the size of that list matters more now than it did last year.

Is ECH the same thing as Encrypted SNI?

ECH is the successor. Encrypted SNI was an earlier draft that encrypted only the server name field and was never standardized. ECH encrypts the entire inner ClientHello, which closes the side channels that made ESNI leaky, and it is the version that reached RFC status as RFC 9849. Any product documentation still written against ESNI is out of date.

Does dope.security need to block ECH to enforce policy?

No. The dope.security agent runs on the device and inspects the request at the operating-system layer before the TLS session is constructed, so the destination, the URL path, the headers and the payload are all visible without touching the handshake. Users keep the privacy benefit of ECH on the wire, and the security team keeps full visibility on the endpoint it manages.

The field was never yours to depend on

To put the thesis another way: for twenty years the security industry read a hostname out of a field that existed to help servers pick a certificate, and treated that accident as an architecture. ECH is the point where the accident ends. Once the handshake is opaque, a control on the network can only stay useful by preventing clients from using a standard their vendors are shipping, and that is a losing position measured in browser releases.

The controls that survive are the ones that were never reading the network. dope.security inspects on the device, so the destination is visible because the user is right there typing it, not because a protocol left it lying in the open. If you want to see what that looks like against your own traffic, book a 20-minute demo or start a trial from the Fly Direct Secure Web Gateway page.