Cloudflare hosted sites are not SSL decrypted due to ECH (encrypted client hello).

Products

• Cloud Secure Web Gateway - Cloud SWG
• ProxySG Software - SGOS

Issue/Introduction

Some SSL-secured websites are no longer TLS decrypted because they don’t match the hostname or category rules in the Edge SWG or Cloud SWG SSL Intercept layer policy due to usage of the emerging ECH (encrypted client hello) standard. Currently, all of these websites are Cloudflare hosted. When this occurs, the hostname presented to Edge SWG policy is cloudflare-ech.com, rather than the original hostname such as example.com.

Cause

On September 27, 2024, Cloudflare announced that they had enabled ECH for their free tier of service and made ECH an optional setting for their paid accounts. During their previous ECH trial, around 4 million websites (some trustworthy and some untrustworthy) were ‘hidden’ from TLS inspection behind the cloudflare-ech.com domain. This caused legitimate inspection and enforcement devices throughout the world that rely on the plain-text SNI to no longer work as expected with the ECH-enabled Cloudflare websites.

Browser support for ECH has been enabled by default for the past year in all major browsers except Safari.

ECH only applies to transparent connections (as explicit proxied connections do not yet support ECH and are therefore unaffected by this change).

If traffic using ECH isn't decrypted, logs and filtering controls will show and operate on cloudflare-ech.com instead of the real destination host. Policy that controls TLS decryption based on destination host or categories will also no longer apply correctly to ECH traffic. 

The diagrams below illustrate how the issue typically manifests.

 

Diagram 1: Traffic without ECH

Prior to ECH, a company has a typical policy that decrypts and blocks all malicious sites. If a client is trying to connect to malware.com, the proxy tests the SNI value malware.com and it matches rules S1 and T1 and blocks the malicious traffic

 

 

Diagram 2: Traffic with ECH

If the client and the server support ECH, the same proxy policy will no longer categorize and block the malicious traffic. This occurs because the malware.com SNI is now hidden in the encrypted part of the client hello message while the plain-text SNI value points to a gateway on the Content Delivery Network (CDN) that fronts malware.com. This gateway is called a client facing server and it enables the real destination to stay hidden from any network equipment such as a proxy that resides between the client and server.

Resolution

There are two ways to preserve the SNI visibility: 

1. [Recommended] Add the ‘Content Delivery Networks’ category to your TLS/SSL Interception policy (so that all content is decrypted)
2. [Optional] Disable ECH in your browser management controls

 

Cloudflare appears to be the first major CDN to enable ECH but it is expected that others will follow and the percentage of ECH traffic will grow as a result.

Diagram 3: Traffic with ECH correction

In the above diagram, a new S0 rule has been added to decrypt any traffic that matches the ‘Content Delivery Networks’ URL category, or at a minimum the cloudflare-ech.com hostname.

Symantec is adding all ECH client-facing servers into the CDN category which then allows our customers to use this category as a condition for SSL Interception. When the Proxy receives the encrypted client hello targeting the cloudflare-ech.com destination, this hostname will match the CDN category and cause the ProxySG to decrypt this connection. The act of decrypting the connection will cause the browser to silently fall back to a non-ECH connection which sends the real malware.com destination SNI which then matches the policy/category that a customer has configured.