Decoding TLS Encrypted Client Hello extension

01/12/2023 (updated on 10/03/2025) · 12 min read · cybersecurity cryptography privacy tls ech hpke sni  ·
Share on:

Translations

Overview

In this article, I would like to introduce you to Encrypted Client Hello (ECH), an extension of the Transport Layer Security (TLS) network protocol designed to guarantee enhanced privacy. The main idea is to make certain Web browsing information transmitted over the Internet unreadable to unauthorized parties.

Introduction

Web communications via the HyperText Transfer Protocol (HTTP) are now around 95% encrypted (according to Google and Cloudflare). This is made possible by the Transport Layer Security (TLS) protocol. The latter enables encryption and authentication of sessions in which unencrypted data can circulate with a higher level of security (confidentiality and integrity) over a non-trusted network such as the Internet. Although considered robust in its latest version and widely adopted, sensitive information still circulates in clear text using this protocol, and this can be considered as a privacy issue. To counter this, a solution is currently being standardized: Encrypted Client Hello (ECH). We will take a look at why TLS currently has privacy limitations, how the ECH solution works, and how ECH raises new security issues.

TLS 1.3 limitations

The TLS protocol appeared in 1994 in its first version: SSL 1.0. It then evolved with SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 and finally TLS 1.3. It is divided into two sub-protocols:

  • The Handshake Protocol, which authenticates the server and possibly the client, and negotiates cryptographic parameters.
  • The Record Protocol, which encrypts, fragments, transmits, verifies, decrypts and reassembles messages.

TLS 1.3 protocol exchange

With the latest version, TLS 1.3, new significant features have been added compared to previous versions. These include:

  • the removal of deprecated algorithms for symmetric encryption, of Hash-based Message Authentication Code (HMAC, a technique for authenticating a message using an encryption key and a cryptographic hash function) and of signatures;
  • the withdrawal of static key exchange mechanisms without Forward Secrecy;
  • the support for algorithms using elliptic-curves;
  • the use of HMAC-based Key Derivation Function (HKDF);
  • faster session recovery with Pre-Shared Keys (PSK);
  • the protection against cryptographic downgrade by calculating a Message Authentication Code (MAC, an object used to ensure message integrity) for protocol negotiation messages;
  • the reduction in the number of exchanged packets (Zero Round-Trip-Time or 0-RTT) in the Handshake Protocol, speeding up the connection establishment;
  • the encryption of more metadata in the Handshake Protocol.

However, in TLS 1.3, it is still possible to use an extension called Server Name Indication (SNI). This extension is passed in clear text with the first ClientHello TLS packet, and allows the client to indicate to the server the domain name to which it is trying to connect. The server, which can potentially host several services and domain names (referred to as virtual hosting), can then choose the correct associated TLS certificate. In addition, Web filtering systems on the network, such as proxies or next-generation firewalls, use the SNI value to decide whether or not to authorize the TLS connection whose inner content is unreadable for these devices.

Example of Server Name Indication usage

Another extension is also passed in the clear: Application-Layer Protocol Negotiation (ALPN). This extension allows the client, in the ClientHello TLS packet, to indicate which application protocols are supported, and the server to choose one of them and indicate it in the ServerHello response packet. This allows the server to return the correct certificate if it has more than one, depending on the application. This makes it possible, for example, to negotiate the use of HTTP/2 in favor of HTTP/1.1.

Finally, another essential point is that, before establishing a TLS connection, the client must generally first carry out a Domain Name System DNS query to determine the Internet Protocol (IP) address to contact from a domain name. By default, these requests circulate unencrypted on the network.

These practices (SNI, ALPN, DNS) are essential, but since they generate unencrypted data transfers, they disclose information that can compromise users’ privacy. Several initiatives aim to mask the transfer of such information. These include:

  • DNS-over-TLS (DoT), which consists in sending DNS requests through an encrypted TLS session.
  • DNS-over-HTTPS (DoH), which consists in sending DNS requests through the HTTP protocol, itself encapsulated in TLS.
  • DNS-over-QUIC (DoQ), where DNS requests are routed through the QUIC protocol (a transport protocol based on the User Datagram Protocol or UDP).
  • Encrypted SNI (ESNI), which encrypts the SNI within the ClientHello TLS packet. It has been abandoned in favor of ECH, which may be more widely adopted.

Recap of the network initiatives for browsing privacy

Another initiative, ECH, began to emerge in 2018 and is still being standardized to this day. It is an improvement of the ESNI initiative in that it focuses on masking not just the SNI but a whole set of information contained in the ClientHello TLS packet.

How ECH works

ECH is an extension of the TLS 1.3 protocol, which consists in communicating sensitive information in the ClientHello packet in an encrypted manner. To achieve this, the client retrieves upstream cryptographic information gathered in an ECH configuration published by the server, and then uses it to build a TLS 1.3 ClientHello packet containing two versions of the packet: a public, unencrypted one, and a private, encrypted one.

ECH relies on the recent Hybrid Public Key Encryption (HPKE) standard to perform the encryption and decryption (called encapsulation and decapsulation in HPKE terms) of the private version of ClientHello. I won’t go into detail about HPKE in this article, preferring to redirect you to the standard or this very good article. Broadly speaking, HPKE allows, via a Key Encapsulation Mechanism (KEM), to transmit an encapsulated (encrypted) symmetric encryption key via an asymmetric public key, and then to decapsulate (decrypt) it via the associated asymmetric private key. For more information on the concepts of symmetric and asymmetric encryption, I refer you to another of my articles.

ECH configuration retrieval

An ECH configuration contains an identifier, an HPKE public key, a cipher suite (set of cryptographic algorithms) and a public domain name. To share the ECH configuration with clients, the server generally uses another protocol: DNS. Indeed, beyond domain name resolution, DNS is widely used to share infrastructure information on the network. ESNI used TXT or type 16 DNS records to share the public keys used to encrypt the SNI. This type of record is used to store information in text form. Here is an example of a DNS TXT query performed with the dig tool.

$ dig +short txt.thibautprobst.fr txt
"This is a nice TXT record!"

With ECH, configuration is made available via a HTTPS Resource Record (RR) or type 65 DNS record. This type of DNS record is used to store information for delivering configurations specific to a service accessed via the HTTPS protocol. Here is an example to retrieve the ECH configuration of crypto.cloudflare.com:

$ dig +short crypto.cloudflare.com HTTPS
1 . alpn="http/1.1,h2" ipv4hint=162.159.137.85,162.159.138.85 ech=AEX+DQBBNQAgACAeSM3dLHfo+RGkgUXbBhzqU65l5T7hjuGv4Sz7ztXeaAAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:7::a29f:8955,2606:4700:7::a29f:8a55

If we look at the associated DNS packet, we can find all the ECH configuration information:

HTTPS RR DNS response packet for ECH

ECH configurations are then generally retrieved via DoH or DoT to guarantee the confidentiality of these exchanges, and so avoid divulging any further information about the intention to use ECH.

Building and sending ClientHello

If no ECH configuration can be retrieved upstream of the Web communication, it can be preconfigured on the client. Note that if the latter has no ECH configuration available, it must still send a ClientHello TLS packet in which it constructs an ECH extension in the appropriate format but with random values, called Generate Random Extension And Sustain Extensibility (GREASE). This allows the client to advertise ECH willpower and maintain interoperability while it will be ignored by the server anyway here.

Otherwise, if the ECH configuration has been successfully fetched, the ClientHello TLS packet is built as follows:

  • A ClientHelloOuter section including a public SNI (revealing no direct information about the destination Web server) and an ECH extension with the following fields:
    • a ClientHello type: here outer;
    • the ECH configuration identifier;
    • a cipher suite;
    • the HPKE key encapsulated by the public key and used to decrypt the following field;
    • a payload which corresponds to the ClientHelloInner encrypted with the ECH public key, plus Additional Authenticated Data (AAD).
  • A ClientHelloInner section, which is the encrypted portion of the ECH extension of the ClientHelloOuter. It is a second ClientHello packet contained in the first one, where the SNI stands as a private version (the value associated with the destination Web server).

TLS ECH ClientHello packet

ECH acceptance or rejection

Upon receiving the ClientHello ECH packet, the server can act in one of two ways, depending on the ClientHello type:

  • If it is of type outer:
    • If the server supports ECH, it checks the ClientHelloOuter and then tries to extract the ClientHelloInner by decrypting it with its private key. It then forwards the ClientHelloInner to the destination server (which may be itself). This is an ECH acceptance.
    • If, on the other hand, the server doesn not support ECH, it negotiates with the ClientHelloOuter. This is an ECH rejection.
  • If it is of type inner, the server sends a classic TLS response of type ServerHello, except for the random field, which is derived from the random field of the received ClientHelloInner packet. The server can also respond with a HelloRetryRequest packet containing an ECH extension indicating ECH acceptance asking to resend the ClientHello ECH packet, since in this case it has provided the server with an ECH configuration. If the HelloRetryRequest message does not contain an ECH extension, this corresponds to an ECH rejection.

In the standardization document, a theoretical dissociation is made between the server handling the ClientHelloOuter (called the client-facing server) and the server handling the ClientHelloInner (called the backend server).

Of course, it should also be noted that with ECH, the server will only accept TLS version 1.3 or higher.

Testing ECH

In this section, we will test ECH and check how it works. To do so, at the time of initially writing this article, I’m using the Mozilla Firefox browser in version 120 (where ECH is enabled by default, the minimum version required for ECH being 118) on MacOS Ventura version 13.3.1, at the time of writing this article. Mozilla Firefox relies on DoH to retrieve ECH configurations.
In Firefox, in the address bar, type about:preferences, go to Privacy and Security and in the DNS over HTTPS section, choose Increased Protection (you can leave Cloudflare as default provider).

First step of ECH configuration in Firefox

Then, in the address bar, type about:config, then in the search bar type network.dns.echconfig.enabled and make sure the network.dns.echconfig.enabled entry is set to true.

Second step in ECH configuration in Firefox

Then, using Mozilla Firefox, navigate to a website supporting ECH, such as https://tls-ech.dev or https://crypto.cloudflare.com/cdn-cgi/trace, which will then explicitly tell you in the HTML response page whether you are using ECH or whether the SNI is encrypted.
If we look at the associated packet capture, we find in the TLS header the public SNI (here public.tls-ech.dev) and the ECH extension containing the fields we mentioned earlier.

ECH packet capture

ECH issues

With ECH, network security mechanisms such as proxies, next-generation firewalls or other Web Applications Firewalls (WAF) will find themselves unable to perform Uniform Resource Locator (URL) filtering, website reputation or TLS decryption. Indeed, the inability to read the SNI field in the ClientHelloInner makes these mechanisms blind regarding the actual destination of the Web flows, and thus the filtering or decryption decision impossible. This can lower an organization’s level of security or compliance with service recommendations or administrative authorities regarding the traceability of Internet accesses.
Here are the two solutions I foresee currently:

  • Block ECH (and possibly DoH and DoT) in corporate environments, either at the Web browser or network level.
  • Set up a transparent (or reverse) proxy capable of accepting and negotiating ECH for a given set of websites. A good starting point for going at scale could be the Content Delivery Networks (CDNs) now widely present on the Internet.

Conclusion

ECH is an extension of TLS currently being standardized designed to guarantee maximum privacy during secure Internet connections. To achieve this, the SNI field and other parameters are encrypted in the TLS connection negotiation packet, following the HPKE standard. However, this can hamper the effect of web filtering mechanisms, and we thus arrive at a stage where privacy and security have conflicting interests. Deployment at scale of ECH is still a work in progress, due to the technical tasks involved and the constraints of Web filtering mechanisms. To be continued!

Sources

Translations