Encrypted Client Hello – new corporate security challenges brought to you by privacy solutions

“ECH walks into a corporate meeting and says, ‘I’m here to protect privacy!’ The security team replies, ‘Great, but can we at least see who you’re talking to?’ And so the battle begins.”

Encrypted Client Hello (ECH) is an extension of the latest TLS1.3 protocol.
It’s an evolution of previous attempts to secure the SNI (i.e. ESNI).
ECH is designed to enhance privacy by encrypting all sensitive handshake metadata (e.g. SNI, ALPN). As well as better fallback mechanisms.

In the last few years web privacy has been enhanced by implementing solutions such as DNS-over-HTTPS (DoH) and DNS-over-TLS (DoT). ECH brings one more building block to that puzzle by addressing specific privacy gaps in the TLS protocol.

While privacy is something we all cherish as individuals, especially on the wide-web, this actually introduce a big issue for the middleboxes like firewalls, load-balancers, proxies, etc.

These middleboxes become blind to the resource the users are attempting to access and implementing corporate security (and other ) policies becomes much harder. In addition, ECH can actually play to the hand of the bad guys on the web assisting them spreading malware, hosting phising web sites and what not.
This is especially true when adversaries make use of CDNs and similar services to hide behind.

We can conclude that ECH presents challenges not just for corporate organizations, but also for CDNs, content providers, educational institutions, ISPs and more.

We need a solution! And thankfully there is/are, well… partially…

What is SNI?
Server Name Indication (SNI) is an extension to the TLS protocol that allows a client (like a browser) to specify the hostname it wants to connect to during the TLS handshake. This is crucial because it enables a single server or IP address to host multiple secure websites, each with its own TLS certificate, without confusion.

Why is SNI Visibility Important?

• Efficient Hosting: SNI allows hosting providers and content delivery networks (CDNs) to serve multiple websites securely from a single IP address, saving resources and reducing costs.
• Traffic Management: Network devices like load balancers and firewalls rely on SNI visibility to route traffic correctly to the intended backend server or application.
• Security Monitoring: Corporate security tools often use SNI information for filtering, monitoring, and enforcing policies on encrypted traffic. Without visible SNI, these tools may lose critical visibility into what websites users are accessing.

However, because SNI is transmitted in plaintext during the handshake, it can expose sensitive information about which websites users are visiting, leading to privacy concerns. ECH aims to encrypt this information while maintaining functionality.

TLS connection example (with ECH of course)

Let’s follow a session towards https://defo.ie/ech-check.php which is an ECH test webpage. We will assume that we are using an ECH enabled client and for the sake of simplicity we will follow only the IPv4 stream.

1. First a DNS query will be sent, looking for defo.ie entry
   • For full privacy the query of course should be made using DoH/DoT, but it’ll work with regular cleartext DNS as well.
   • The response will contain an entry of type RR (type 65), within it are 3 key elements:
     • IP address of the server we need to contact
     • SNI of the public server we need to use in the ClientHelloOuter
     • A public key with which we should encrypt the ClientHelloInner
2. Following a successful TCP 3-way handshake a TLS1.3 ClientHello will be sent.
   • The ClientHelloInner is encrypted using the server’s public key (via HPKE).
   • The encrypted data is embedded in the “encrypted_client_hello” extension of ClientHelloOuter.
3. The server will decrypt the extension and forwards the ClientHelloInner to the backend server to complete the handshake.
4. A successfully established session would provide the following result:
   

ECH Implementation
ECH is intended to be widely spread and utilized even if the DNS entry doesn’t provide the necessary information by generating dummy ECH extension with random data. The idea is to make it harder for network observers to distinguish between real ECH traffic and fallback traffic. This helps to conceal whether a client is actually using ECH or not.

This is done by a mechanism called GREASE (Generate Random Extensions And Sustain Extensibility), besides the conceal part, it’s there to encourage vendors to adopt and support the new extension for smooth deployment across the internet. In addition, making all ClientHello messages appear similar, GREASE prevent from middleboxes treating ECH traffic differently.

Servers that do not support ECH are required by TLS specifications to ignore unrecognized extensions, including GREASE-generated ones. This ensures compatibility with non-ECH servers, the server will process the ClientHelloOuter only.

In case GREASE-generated ClientHello received on a server that does support ECH, it ignores the encrypted_client_hello and completes the handshake using the ClientHelloOuter.

How can we gain lost visibility?
Block ECH parameters retrieval
Clients retrieve ECH parameters from DNS records. Hence various middlebox vendors which provide DNS security solutions were adapted to strip ECH parameters from DNS response. The client will be forced to send dummy GREASE data (if ECH is enabled) and by that forcing a fallback causing clients to use ClientHelloOuter, exposing unencrypted SNI and other details.

Block TLS1.3

By blocking TLS1.3, the client will be forced to fallback to older TLS version (e.g. TLS1.2) which doesn’t support ECH.

Note that downgrading TLS version is discouraged as it compromises security.

Force Fallback

TLS1.3 with ECH has a mechanism that can indirectly detect tempering (e.g. MITM) and force a fallback. It’s not an explicitly designed mechanism, but rather inherent to how ECH and TLS handshake work. The bottom line is that enabling SSL deep inspection will force fallback causing clients to use ClientHelloOuter, exposing unencrypted SNI and other details.

Other fallback mechanisms might include tempering specifically with the enctypted_client_hello, corrupt part of the payload or remove critical fields, forcing decryption failure on server side, leading to fallback.

Utilize enterprise Browser

An enterprise browser is a specialized web browser designed for corporate environments, offering enhanced security, granular control, and integration with enterprise tools to address the unique needs of businesses. Unlike consumer browsers (e.g., Chrome, Edge), enterprise browsers embed security and management features directly into the browser to protect corporate data, enforce policies, and optimize productivity without disrupting user workflows.

Enterprise browsers operate at the endpoint level, where they have access to web traffic before it is encrypted or after it is decrypted by the browser itself. This eliminates the need for traditional MITM (Man-in-the-Middle) decryption methods, which often face issues with certificate pinning. By thus providing full visibility without protocol tampering.

Back to our ECH issue – Enterprise browser provide full visibility into the ClientHelloInner information providing the tools to apply security/routing policies.

Conclusion

Today ECH is enabled by default on Chrome and Mozilla Firefox, while other browsers have the capability, they require manual activation (Edge, Brave, Safari).

In the future ECH might be enforced on the server side and later might be enforced on the browser level as well, which will make solutions like DNS ECH filtering and force fallback obsolete.
To support this new protocol extension while not compromising on corporate security policies, the most elegant solution is the enterprise browser.
Other solutions are either incomplete or at risk of being deprecated.

More attention needs to be paid to the security controls of different DNS flavors, particularly the encrypted ones (DoT and DoH).
If you want to have an intelligent conversation about intelligent security enforcement in the modern internet feel free to reach out.

Grigory Levitin

System Architect