How Encrypted Client Hello Hides SNI in TLS 1.3 and Firefox

This article provides a comprehensive overview of Encrypted Client Hello (ECH) within the TLS 1.3 protocol and explains how it enhances user privacy by concealing the Server Name Indication (SNI). Historically, even during secure HTTPS connections, the SNI remained visible in plaintext, allowing network observers to see which websites a user was visiting. Below, we will break down what SNI and ECH are, how the encryption mechanism works, and how the Firefox web browser implements this technology to secure your browsing activity from prying eyes.

The Privacy Gap: Plaintext SNI in TLS 1.3

Transport Layer Security (TLS) 1.3 is the protocol responsible for encrypting data between your web browser and the websites you visit. To establish this secure connection, the browser and the server perform a "handshake," which begins with the browser sending a "Client Hello" message.

Inside this Client Hello message is a field called the Server Name Indication (SNI). Because a single server IP address often hosts hundreds of different websites, the SNI tells the server the exact domain name the user is trying to reach so the server can send back the correct security certificate.

The problem is that the Client Hello happens before the encrypted connection is established. Consequently, the SNI is sent in plaintext. Even though an Internet Service Provider (ISP), government censor, or malicious actor on a public Wi-Fi network cannot see what you are doing on a website, they can read the SNI to see which website you are visiting.

What is Encrypted Client Hello (ECH)?

Encrypted Client Hello (ECH) is an extension for TLS 1.3 designed to close the SNI privacy loophole. ECH is the evolution of an earlier, flawed attempt called Encrypted SNI (ESNI). While ESNI only encrypted the server name, ECH encrypts the entire Client Hello message, including the SNI and other sensitive handshake parameters.

ECH solves the plaintext problem by splitting the Client Hello message into two parts:

  • ClientHelloOuter: This is the public part of the message that remains in plaintext. It contains non-sensitive connection details and a generic "public name" for the SNI—usually the name of a Content Delivery Network (CDN) or hosting provider, such as Cloudflare or Fastly.
  • ClientHelloInner: This is the encrypted payload hidden inside the outer message. It contains the actual, sensitive connection details, including the true SNI (the real website you want to visit).

When a network observer intercepts the connection, they can only read the ClientHelloOuter. They know you are connecting to a large hosting provider, but they cannot tell which specific website on that provider's network you are accessing.

How Firefox Hides SNI Using ECH

Mozilla introduced native support for Encrypted Client Hello in Firefox 118. For Firefox to encrypt the SNI before the TLS handshake even begins, it needs to acquire a public encryption key from the website's server beforehand. Firefox accomplishes this by combining ECH with another privacy technology: DNS-over-HTTPS (DoH).

Here is the step-by-step process of how Firefox hides your SNI using ECH:

  1. The Encrypted DNS Request: When you type a URL into Firefox, the browser must find the website's IP address. Instead of using standard, unencrypted DNS, Firefox uses DNS-over-HTTPS (DoH) to securely ask a DNS server for the website's information.
  2. Retrieving the ECH Key: If the destination website supports ECH, its DNS records will include a specific HTTPS record. Along with the website's IP address, this record contains the server's public ECH encryption key. Firefox downloads this key securely over the DoH connection.
  3. Constructing the Handshake: Firefox uses this public key to encrypt the ClientHelloInner (which holds the real SNI). It then wraps this encrypted data inside the ClientHelloOuter (which displays the generic server name) and sends the packet to the server.
  4. Decryption at the Server: The hosting provider receives the message. Using its private key, the provider decrypts the ClientHelloInner, reads the true SNI, and routes your Firefox browser to the correct website.

Requirements for ECH to Work in Firefox

Firefox enables ECH by default, but the hiding of the SNI only occurs if three conditions are met:

  • DNS-over-HTTPS is Active: Firefox must have DoH enabled (which is the default in many regions under Firefox's "Increased" or "Max" DNS protection settings) to securely fetch the ECH keys. If standard DNS is used, a network observer could simply read the DNS request to see what website you are visiting, rendering ECH useless.
  • Website Support: The website you are visiting must be hosted on a server or CDN that actively supports ECH and publishes its ECH public keys in its DNS records.
  • TLS 1.3 Usage: Both the browser and the server must be communicating via TLS 1.3, as ECH is not backward-compatible with older versions like TLS 1.2.

By pairing DNS-over-HTTPS with TLS 1.3's Encrypted Client Hello, Firefox successfully seals the final major metadata leak in modern web browsing, ensuring that your browsing history remains strictly between you and the websites you visit.