When you follow today's discussion about Encrypted ClientHello (ECH), you can easily get the impression that ECH is a general threat to enterprise cybersecurity. I would like to offer a different perspective. Instead of treating ECH as an opponent that has to be suppressed, we can make it part of the security architecture.

When you read setup guides for SSE security gateways, a common recommendation is to block HTTPS record queries or remove the ECH configuration from the DNS response. But our implementation shows that, used correctly, ECH does not take visibility away from the authorized security gateway. It protects the connections on both sides of it and can help the SSE industry deliver on its promise to protect sensitive customer data.

In other words: ECH and cybersecurity can actually become very good friends.

A very short ECH recap

The first TLS message from a client is the ClientHello. Traditionally, it exposes the Server Name Indication (SNI), which tells everybody observing the connection which server the client wants to reach.

ECH changes that. The client builds a ClientHelloInner containing the real server name and the real TLS parameters, encrypts it with a public key learned from the server's DNS HTTPS record, and carries it inside a ClientHelloOuter. An observer can see only the shared public name from the outer message. The server that owns the matching ECH private key decrypts the inner message and continues the real TLS handshake.

That is the short version. For a deeper explanation of the inner and outer ClientHello, ECH rejection, public names and the role of encrypted DNS, see Encrypted ClientHello (ECH) in the SSE TestCenter resources.

One point remains essential here: ECH protects the hostname only if the DNS query that delivered the ECH configuration is protected as well. If the client asks for the name over plain DNS, an observer already knows the answer before the TLS connection starts.

Today's SSE vendor challenge

SSE vendors use an authorized TLS man-in-the-middle proxy. The technique has been around for about 25 years and has become a standard way for enterprises to enforce security policy on encrypted web traffic.

The managed client trusts a root CA belonging to the gateway. The gateway terminates the TLS connection from the client and opens a separate TLS connection to the origin server. On the upstream connection, the gateway validates the origin's certificate and decides whether the connection is trustworthy. On the downstream connection, it creates a certificate for the requested server on the fly and signs it under the gateway's trusted CA chain so that the managed client accepts it.

Between these two connections, the security gateway sees the plain HTTP request and response and can enforce the customer's policy.

But this concept breaks when the browser encrypts the ClientHello for the origin's ECH service and that handshake arrives at a proxy which does not own the matching private key.

This is not only a matter of hiding the SNI string. Even if the proxy learned or guessed the intended hostname from somewhere else, it still could not reconstruct and accept the ClientHelloInner. The inner handshake, its transcript and the server's ECH acceptance signal are cryptographically bound together. Only a server that decrypted the ClientHelloInner can prove to the client that it accepted that inner handshake.

The proxy can reject ECH and complete a handshake for the public name from the ClientHelloOuter, but RFC 9849 deliberately makes that connection unusable for application data. The client aborts it and may retry with a new ECH configuration or, if ECH was securely disabled, without ECH. Such a retry may restore connectivity, but it restores it by giving up the privacy ECH was meant to provide.

So yes: the intended intercepted TLS handshake really fails. Guessing the hostname does not repair it.

This explains the defensive reaction we see today. If a gateway cannot participate in ECH, suppressing the ECH information in DNS keeps the established inspection model working. But it also removes the privacy improvement for the managed user.

Suppressing ECH may be a pragmatic short-term answer, but the cybersecurity industry should not mistake it for a long-term architecture.

How long will blocking ECH remain viable?

We have seen this pattern before: In the early days of TLS scanning, one common response to HTTPS traffic that a security product could not inspect was to disable HTTPS or force the connection back to HTTP. That preserved filtering visibility by lowering the security of the connection. It worked only while HTTP was still considered an acceptable alternative. As HTTPS became the normal way to use the Web, browsers started warning about HTTP, websites stopped offering it, and security gateways had to learn how to participate in TLS instead of holding it back.

What will happen with ECH? Will browsers eventually warn that a connection lacks the privacy protection they normally expect? Will websites one day treat a connection without ECH as a legacy path that may not come from a modern browser? Nobody can answer those questions today. But ECH is already moving from experiment to baseline: Firefox has rolled it out worldwide, and Chromium describes its ECH rollout as fully launched. It would be dangerous to build a security architecture on the assumption that ECH can always be removed without consequences.

The cybersecurity industry must keep up with these innovations. If our answer to every new Web protection is to disable it, we risk painting ourselves into a technological corner. Security gateways should allow the Web to become more secure and more private, not require it to remain at yesterday's level so that inspection continues to work.

Let the security gateway participate in ECH

The solution is actually straightforward for an SSE platform that integrates Web Security with DNS Security: the SSE gateway runs both the DNS gateway and the Web gateway.

We then apply the same well-proven technique once more. Just as the SSE gateway separates the web connection into a downstream and an upstream TLS connection, it also controls the two DNS paths needed to describe those connections correctly.

In the first two articles of our DNS Security series, we described why the path to the DNS resolver must be protected and why the gateway's DNS policy should build a coherent A, AAAA and HTTPS answer for the path it selected. ECH is the logical next step.

When the DNS request arrives from the client and the policy decides that the connection should be inspected, the DNS gateway does not pass through the origin's ECH configuration. That configuration belongs to the origin's edge and would be wrong for a connection that is being directed somewhere else.

Instead, the gateway returns its own addresses, its own protocol offer and its own ECH configuration in the HTTPS answer. The answer describes the service that the browser will really contact: the web gateway.

The browser then connects to the web gateway and encrypts its ClientHelloInner with the gateway's ECH public key. The gateway owns the private key, decrypts the message and receives the real SNI and the complete ClientHello. Certificate generation, protocol negotiation and security policy continue just as they did before ECH.

For the second connection, the gateway resolves the real origin through its encrypted upstream DNS service. It receives the origin's current HTTPS record and ECH configuration and uses that configuration when it opens the upstream TLS connection. This works independently for HTTP/1.1, HTTP/2 and HTTP/3.

For traffic that the policy sends directly to the origin, nothing needs to be replaced. The DNS gateway preserves the origin's own records, including its ECH configuration, and the browser uses ECH with the origin as intended.

The important detail is that the origin's ECH data is not simply removed. It is replaced with the ECH data for the path selected by policy. The browser gets a truthful description of the service it is about to contact.

Delivering on the SSE promise

This technique does more than solve a compatibility problem for the security gateway. It provides a real privacy benefit.

The mission of a Security Service Edge is to protect sensitive customer information against attacks. When an employee performs sensitive web research, the list of sites they visit can itself be sensitive information. Protecting the content while exposing every destination name on the network is an incomplete result.

In some deployments, the connection between the managed device and the SSE service is already inside an encrypted tunnel. In others, HTTPS connections are simply directed to the security gateway through DNS or network policy. On that path, an attacker able to observe the traffic can otherwise read the SNI from every ClientHello.

This is where an SSE gateway with ECH can provide even stronger destination privacy than origin ECH alone.

With ordinary origin ECH, the observer still sees the destination IP address and the public name of the origin's CDN or edge service. The real site is hidden among the sites sharing that infrastructure, which is valuable, but the visible IP address and public name can still narrow the possibilities.

With gateway ECH, every inspected connection from the client goes to the same SSE edge and presents the same gateway public name. The observer on that network leg does not see a different IP address or public name for every destination. The anonymity set is no longer only the websites sharing one origin edge. It is the inspected web traffic that the customer's users send through the SSE gateway.

That is a substantial privacy improvement, not a minor side effect. A central SSE edge is an ideal place to make ECH effective.

The gateway itself still sees the real name. That is deliberate: it is the trusted policy enforcement point. But an external observer between client and gateway sees only the gateway identity. On the other side, the gateway uses the origin's ECH configuration so that an observer of the upstream connection does not see the origin SNI either. And when both DNS paths are encrypted, the name is not given away by the preceding DNS queries.

There is one remaining operational concern. When a central gateway resolves the origin, a CDN may choose an endpoint for the gateway's location rather than for the client's location. Our implementation can preserve an approved, privacy-bounded client network context through EDNS Client Subnet so that DNS-based regional selection still works. That deserves its own article, and it will be the next part of this series.

What Cloud Fellows offers

With Cloud Fellows Web Gateway version 1.2.0, we offer ECH support on both sides of the security proxy. The gateway accepts and decrypts ECH from managed clients, publishes its rotating ECH configuration through its DNS service, and uses the origin's ECH configuration for its own upstream connections over HTTP/1.1, HTTP/2 and HTTP/3.

As far as we know, this is the first commercially available SSE forward proxy with that complete combination. If you know another one, please keep us honest.

To our customers, we offer a full-featured SSE security gateway combining the DNS gateway and the web gateway for the full family of modern web protocols, controlled by one flexible policy engine.

To our partners, we offer the technology and expertise to integrate these capabilities into their own solutions, following our mission to help the SSE industry improve through innovation.

To researchers, SSE TestCenter provides a free way to explore how a current Internet connection handles DNS queries, HTTPS records, Encrypted ClientHello and the final web connection. The DNS and Web Visibility test brings the DNS and TLS observations together in one view.

ECH does not have to be disabled for security inspection to survive. Once DNS and web policy describe the same path, ECH becomes part of the protection rather than an obstacle to it.