Encrypted Client Hello Is Here to Stay

Encrypted Client Hello (ECH), standardised by the IETF in RFC 9849, is rapidly becoming a normal part of Internet connectivity.

Google’s introduction of platform support for ECH in Android 17 is an important milestone. ECH itself is not new: Chrome enabled it starting with Chrome 117 in September 2023, followed closely by Firefox 119 in October 2023. Chromium-based browsers such as Microsoft Edge subsequently gained support as well. The vast majority of modern desktop browsers are therefore already ECH-capable. Android 17 confirms that ECH is moving beyond a browser-specific feature and becoming part of the mainstream application networking platform.

This is good news for Internet privacy.

TLS has long protected application data, including the URI being accessed, credentials, HTTP headers and content. But one particularly useful piece of metadata has traditionally remained visible: the Server Name Indication (SNI) extension in the TLS ClientHello, which normally identifies the hostname the client intends to contact.

ECH protects the real SNI, along with other sensitive ClientHello information, from passive network observers.

For enterprises, however, this deliberately changes an assumption that many security architectures have relied on for years: the SNI visible in a TLS ClientHello can no longer be assumed to identify the service the client is actually accessing.

Fortunately, protecting user privacy and maintaining strong enterprise security are not mutually exclusive.

From SNI to ECH

SNI was created to solve a very practical problem.

With HTTP, multiple websites can share the same IP address because the HTTP Host header tells the server which site the client wants. With HTTPS, TLS takes place before the HTTP request, so the server needs to know which certificate to present before it can read that encrypted Host header.

Assigning a unique IPv4 address to every HTTPS service was not practical, and universal IPv6 deployment was nowhere close when the problem needed to be solved. SNI provided an elegant solution: put the hostname into the TLS ClientHello, allowing the server to select the correct certificate before establishing the encrypted connection. The inevitable consequence was that the hostname remained visible.

Over time, SNI became useful for much more than virtual hosting. Enterprise security products used it for traffic classification and access control. Parental-control services used it for filtering. Security proxies used it to decide whether a connection should be decrypted or bypassed, for example when dealing with certificate-pinned applications. Censorship systems discovered the same signal.

The first attempt to address the privacy issue was Encrypted SNI, or ESNI. The IETF work subsequently evolved into ECH, protecting the sensitive ClientHello rather than only one extension.

That broader design also incorporated ECH GREASE. An ECH-capable client can send a realistic-looking dummy ECH extension even when it is not actually using ECH. This prevents the mere presence of the ECH extension from becoming a reliable signal for classification or blocking.

This matters because both real ECH and GREASE ECH normally still contain a visible SNI. With real ECH, that SNI is normally a cover name while the actual destination is protected. With GREASE, the visible SNI is normally the real destination. An observer cannot simply see the ECH extension and assume it knows what the visible SNI means.

How ECH Works, in Brief

ECH-capable services normally advertise their configuration using HTTPS or SVCB DNS records. This does not require DNS over HTTPS or DNSSEC; those provide different and complementary protections.

The ECH configuration includes a public key and a public_name identifying the client-facing service.

The client then constructs two TLS ClientHello messages:

1. ClientHelloInner contains the real SNI and the TLS parameters the client actually wants to use.
2. ClientHelloOuter is visible on the network. It normally contains the ECH public_name as its SNI and carries an encrypted representation of ClientHelloInner.

If the destination successfully processes ECH, the TLS connection proceeds using the Inner ClientHello. The Outer ClientHello is therefore not an authoritative description of the actual connection.

ECH is also deliberately downgrade resistant. If a server cannot process ECH, the client does not simply retry in plaintext. The rejection first has to be authenticated. In particular, the client authenticates the TLS peer against the ECH public_name. Only an authenticated peer can provide updated ECH configuration or securely indicate that ECH is unavailable.

This distinction is important for enterprise environments. An arbitrary device on the network cannot simply strip ECH and make the client reveal its real SNI. A legitimate TLS inspection proxy explicitly trusted by a managed endpoint has a different relationship with the client and can participate in this authenticated fallback.

What Changes for Enterprise Security?

ECH intentionally makes visible SNI less trustworthy. That matters particularly where enterprises use SNI to decide which connections should bypass TLS inspection.

Consider a certificate-pinned application. Because the application may reject certificates generated by a TLS inspection proxy, an enterprise might historically create an exception such as:

If SNI is updates.pinned-app.example.com, bypass TLS inspection.

That rule assumes the SNI proves that the connection actually belongs to the pinned application. It does not.

With ECH, the visible SNI may be a cover name rather than the true destination. A malicious client can also deliberately construct an Outer ClientHello containing an SNI chosen to influence network policy. A broad SNI exception intended for one application can therefore become an attractive evasion mechanism for unrelated traffic.

There is a second, subtler risk. A malicious client can put deliberately unsuitable TLS parameters into ClientHelloOuter, for example unsupported supported_groups values or a key_share that an inspection proxy cannot use. At the same time, it can place completely valid TLS parameters inside the encrypted ClientHelloInner.

An ECH-capable destination that decrypts the Inner ClientHello can establish the connection normally. The enterprise proxy, however, sees only an Outer ClientHello that it cannot successfully inspect.

If the security policy responds to that situation by classifying the connection as “undecryptable” and allowing it through without inspection, the attacker has achieved precisely the desired result.

The important lesson is not that ECH is a security problem. It is that ECH makes security policies based on unauthenticated network hints increasingly fragile.

Handling ECH Safely with Zscaler Internet Access

Zscaler Internet Access uses multiple complementary controls to address these scenarios. The objective is not to weaken ECH, but to avoid depending on visible SNI as the sole source of truth.

Control ECH discovery through DNS

The most straightforward place to prevent ECH negotiation when TLS inspection is required is before the TLS connection begins.

Clients normally obtain ECH configuration through the ech parameter of HTTPS or SVCB DNS records. ZIA DNS Control can inspect DNS over UDP and TCP, as well as DNS over HTTPS when that traffic traverses ZIA and is decrypted.

Zscaler recommends blocking HTTPS and SVCB resource-record queries where ECH needs to be suppressed and returning DNS response code 2, SERVFAIL. Ordinary A and AAAA resolution remains available, so the application can continue by establishing a conventional TLS connection without having obtained an ECH configuration.

An ECH-capable client may still send ECH GREASE. That is expected and does not mean genuine ECH is being used.

The current approach blocks the complete HTTPS/SVCB response and therefore also removes other information the record might contain. A future enhancement will make this more surgical by removing only the ech parameter while preserving other service hints.

Use authenticated ECH fallback with trusted TLS inspection

DNS control alone is not sufficient. A client may already have an ECH configuration cached, or it may have obtained one through another mechanism.

In that case, ZIA can make use of ECH's own authenticated fallback behaviour.

When ZIA terminates the Outer TLS connection, the client does not receive a valid ECH acceptance confirmation and considers ECH rejected. ZIA then presents a certificate for the visible ECH public_name.

On a managed endpoint configured to trust the Zscaler inspection CA, that certificate can be authenticated successfully. If no usable replacement ECH configuration is supplied, the client can securely disable ECH, close the first connection and establish a new one without ECH. The real SNI is then visible for TLS inspection.

This is fundamentally different from stripping ECH in transit. The client itself chooses to retry without ECH only after an authenticated TLS exchange. An arbitrary network intermediary that is not trusted by the endpoint cannot do the same thing.

Bind the SNI to the destination with Optimize DNS Resolution

Even after genuine ECH has been suppressed, blindly trusting SNI can still be dangerous.

A malicious client might connect to an attacker-controlled IP address while putting the SNI of a trusted or inspection-exempt application into the ClientHello.

Optimize DNS Resolution provides another layer of protection. ZIA can independently resolve the hostname visible in SNI or HTTP and, where appropriate, use its own resolution result rather than the destination IP supplied externally by the client.

The client can therefore no longer freely combine a trusted-looking SNI with an attacker-selected destination IP address.

Zscaler specifically identifies mitigation of ECH-based domain-fronting evasions as one of the security benefits of this capability. DNS Optimization can also operate when SSL/TLS inspection itself is bypassed, because the visible SNI remains available as an input to resolution.

Replace broad SNI bypasses with Endpoint Context

There is an even stronger answer to the problem of certificate-pinned applications.

Instead of assuming that any connection carrying a particular SNI must have originated from the trusted application, Zscaler Endpoint Context can provide information about the process that actually created the connection.

Endpoint Context collected through Zscaler Client Connector can include application name and publisher, cryptographic hashes, and code-signing certificate information. That context can be incorporated into SSL/TLS Inspection and other security policies.

This allows an inspection exception to become much more precise.

Instead of:

If SNI is updates.pinned-app.example.com, bypass TLS inspection.

a policy can effectively say:

If the originating process has a cryptographic signature of expected certificate-pinned application and SNI is updates.pinned-app.example.com, bypass TLS inspection.

Traffic using the same SNI but originating from a browser, an unknown process or malware does not automatically inherit the exception.

This is a stronger policy model even without ECH. ECH simply makes the limitations of destination-only exceptions much more visible.

Do not fail open on an unusable Outer ClientHello

Finally, a client should not be able to escape inspection simply by deliberately constructing an Outer ClientHello that the proxy cannot process.

ZIA SSL/TLS Inspection policy provides a Block Undecryptable Traffic option. When enabled, traffic that cannot be processed for inspection is blocked instead of automatically being allowed through.

Legitimate applications that cannot tolerate TLS inspection should receive explicit, narrowly scoped exceptions, ideally based on Endpoint Context where possible.

The principle is simple: failure to inspect must not itself become a credential for bypassing inspection.

ECH Is Here to Stay

ECH fixes a genuine privacy weakness in TLS. Users should not have to disclose every hostname they access to every network that happens to forward their packets.

Its growing deployment should be welcomed.

At the same time, ECH means enterprises can no longer build security policy around the assumption that a plaintext SNI is authoritative. Fortunately, managed enterprise environments have stronger signals available.

DNS visibility can control ECH discovery where inspection is required. Trusted TLS proxies can use ECH's authenticated fallback rather than attempting to circumvent the protocol. Optimize DNS Resolution can bind visible hostnames more closely to their real network destinations. Endpoint Context can make certificate-pinning exceptions application-aware. Fail-closed handling prevents intentionally unusable TLS handshakes from becoming a bypass.

SNI was never intended to be a universal application identity mechanism. It became one because it was convenient, visible and usually accurate enough.

ECH deliberately changes that.

Encrypted Client Hello is here to stay. Enterprise security needs to evolve with it.