We’ve spent years trusting the browser padlock to keep our web traffic safe, but enterprise firewalls relied on a quiet compromise to keep networks secure. Now, with ECH encrypting the final piece of plain text in the TLS handshake, the network packet is officially going blind.
For over a decade, the browser padlock icon signified safety. To most, that says that this site is ‘secure’, but what it actually represents is TLS (Transport Layer Security), the foundational protocol that encrypts data travelling across the Internet.
TLS was originally designed to protect password and credit card numbers from bad actors listening on public wifi but it also created a huge challenge for network security. How do enterprise firewalls block content if all web traffic is scrambled? For much basic blocking they’ve been relying on a clever workaround – but a new internet standard known as ECH (Encrypted Client Hello) is about to close that loophole.
Understanding the Basics: TLS & Web Security
First, let’s understand how TLS and Internet Security works. Let’s focus on the browser and how it talks to a web server over TLS:
- HTTP: In the early years, data was sent in cleartext over a insecure channel. Any site you visited on one device, could be viewed on another device on your network, or by your Internet Service Provider.
- HTTPS / TLS: This was solved by TLS by essentially scrambling the conversation. Once a secure connection was made, nobody in the middle could read the content, such as private messages or credentials.
During that initial ‘digital handshake’ as you connect to the website, your browser sends a message called the Server Name Indication (SNI). Picture it a bit like the delivery address on the front of the envelope. The content of the website is still in the envelope and not readable, but the web address is in plain text so that routers know where to send the packet.
How Enterprise Security Relies on Cleartext SNI
Secure Web Gateways, or Next-Gen Firewalls – those Enterprise Security appliances have been used as primary security control – and why not? SSL decryption adds overhead, both in time and CPU cycles – it’s computationally expensive. Without opening that envelope those enterprise security appliances can check whether a user is connecting to a malicious C2 domain, whether or not the domain they are visiting is restricted or unapproved, and whether that traffic should be permitted or blocked.
| Product Type | Vendors / Platforms | Primary Non-Decryption Mechanism | Impact of ECH |
| Next-Gen Firewalls (NGFW) | Palo Alto Networks, Fortinet, Cisco, Check Point | SNI Inspection / App-ID matching | SNI hidden; traffic appears as generic CDN IP |
| Cloud SSE / Security Gateways | Zscaler (ZIA), Netskope, Cloudflare Gateway | Edge SNI matching without full TLS termination | Cannot apply uninspected URL/C2 filtering policies |
| DNS-Level Control | Cisco Umbrella, Enterprise Resolvers | Hostname lookup & ECH parameter responses | Stripping ECHConfig forces fallback to standard TLS |
Enter ECH: Encrypting the Envelope Address
We’ve established that cleartext SNI was really useful for enterprise firewalls, but they weren’t the only beneficiaries. Internet Service Providers (ISPs), advertising networks, and surveillance states could simply track every domain a user visited by simply reading the SNI header.
There’s been a lot of noise recently though, regarding Internet anonymity and privacy, and ECH (Encrypted Client Hello) has been developed by internet standard bodies and it’s been hailed as one of the biggest wins of recent Internet history. (I’ll come back to this later…)
With ECH, the browser encrypts the entire handshake including the SNI – so if we go back to the envelope analogy, it’s like ECH has put the destination address inside an opaque outer envelope addressed to a generic delivery service (like a CDN).
So for anyone watching where your traffic is going, instead of knowing the domain the traffic is heading to, all that is seen is an outbound connection to a generic CDN such as Cloudflare or Akamai.
The Journey To Mainstream Adoption
This isn’t some pie-in-the-sky idea, this is rapidly becoming the default for internet traffic
- CDN Enablement: Content Delivery Networks host a huge percentage of the web. By enabling ECH at their edge, millions of websites have become ECH-enabled without site owners needing to do anything, or probably even being made aware.
- Browsers: All the major browsers such as Chrome, Firefox, Edge support ECH natively (and have done since roughly 2023)
- Firewall Dropping: Browsers are using automated testing techniques that send encrypted headers during regular connections to prevent legacy firewalls from simply dropping ECH connections without accidentally breaking normal internet traffic.
The Enterprise Security Vendors are Adapting
Because ECH hides the destination address at the packet level, simple in-line inspection is no longer enough, so security architectures are adapting
- Endpoint Controls (XDR & Agents): Instead of figuring out where the packet is going after it has left the device, agents running on the device (like Cortex XDR or GlobalProtect) can see the app request, host process and destination domain before the browser encrypts it into a TLS packet.
- Enterprise DNS Control: Before a browser can use ECH, it must ask the DNS server for the site’s ECH encryption key. If a customer has an Enterprise DNS resolver, they can strip the ECH keys out of the DNS response for corporate devices which means the browser will fall back to a standard (non-ECH) TLS handshake meaning the usual ‘workaround’ can work as expected.
- Decryption Profiles & Browser Management: For managed devices, organisations can deploy root certificates via MDM policies which allows dedicated security proxies to terminate the TLS connection at the perimeter, inspect the destination and re-encrypt the traffic.
Is ECH a good thing then?
Probably the most contentious question I could ask.
There is a camp that says – this is a major step forward for individual privacy on the open web. It eliminates eavesdropping from ISPs, local network operators and in some cases, nation states – but it doesn’t eliminate visibility – it centralises it.
By design, ECH requires an edge intermediary to handle the public key handshake – so it’s no longer across distributed network paths, it’s now squarely in the hands of a select few CDNs; Akamai, Cloudflare and Fastly to name a few. They become the man-in-the-middle that sees everything because the web server and the user trusts that CDN.
ECH solidifies CDNs as indispensable architectural gatekeepers, giving them unprecedented leverage over both web privacy and enterprise traffic flows.
If you’re in enterprise security, then this is a transition – the network packet alone is no longer the sole source of visibility. Thankfully, some of the more forward thinking ones, have introduced Enterprise Browsers (like Prisma Browser) can see the packet and destination in cleartext, it performs the security elements (such as DLP, URL filtering and threat checks) before the packet is encapsulated into TLS 1.3 and ECH – clever huh?
As protocol standards like ECH are introduced, the security perimeter is officially moving inside the endpoint. The future of enterprise visibility won’t be won by firewalls trying to peek at network packets; it will be driven by Enterprise Browsers and endpoint control planes that enforce security before the packet ever hits the wire.