How Chromium Uses Encrypted Client Hello to Hide SNI

This article provides a comprehensive overview of the Encrypted Client Hello (ECH) standard and its critical role in modern web privacy. It covers the privacy vulnerabilities of the traditional Server Name Indication (SNI) field during connections, defines how ECH resolves this issue through encryption, and details the exact process the Chromium web browser uses to implement ECH and shield user browsing habits from network eavesdroppers.

When a user connects to a website using HTTPS, the browser initiates a Transport Layer Security (TLS) handshake to establish a secure connection. The very first message the browser sends is called the "Client Hello." Historically, this message has included the Server Name Indication (SNI) field in plaintext. The SNI tells the server which specific website the browser wants to reach, which is necessary when multiple websites share a single IP address. Because the SNI is sent unencrypted, passive network eavesdroppers—such as Internet Service Providers (ISPs), coffee shop Wi-Fi operators, or governments—can read it and see the exact domain name a user is visiting, even though the actual content of the website remains encrypted.

Encrypted Client Hello (ECH) is an extension to the TLS 1.3 protocol designed to close this privacy loophole. ECH fixes the plaintext leak by encrypting the sensitive parameters of the handshake, including the SNI. It achieves this by splitting the Client Hello message into two distinct parts: a plaintext "ClientHelloOuter" and an encrypted "ClientHelloInner."

The Chromium web browser—the open-source project that powers Google Chrome, Brave, and Microsoft Edge—implements ECH by combining it with DNS-over-HTTPS (DoH). To encrypt the SNI, Chromium first needs the destination server's public cryptographic key. Chromium uses DoH to securely request the website's IP address and simultaneously fetches an "HTTPS" DNS resource record. This specific record contains the public ECH key for that website. Using DoH is mandatory here; if Chromium requested the DNS record in plaintext, eavesdroppers would simply see the website name in the DNS query, rendering ECH pointless.

Once Chromium has the public key, it constructs the TLS handshake. It places the true, sensitive information—including the actual SNI of the website the user wants to visit—inside the ClientHelloInner and encrypts it using the fetched public key.

Next, Chromium places this encrypted inner message inside the plaintext ClientHelloOuter. Because network protocols still require an unencrypted SNI field to route the traffic correctly, Chromium puts a generic, public-facing domain name in the outer SNI field. This generic name usually belongs to the Content Delivery Network (CDN) or hosting provider managing the target website (for example, cloudflare-ech.com).

As the data travels across the internet, network eavesdroppers can only read the ClientHelloOuter. They can see that the Chromium browser is connecting to a large CDN, but they are completely blind to the specific website being accessed inside that CDN's network. When the packet reaches the CDN, the server uses its corresponding private key to decrypt the ClientHelloInner, reads the true SNI, and privately completes the connection to the requested website.