ECH closes the last plaintext gap in HTTPS

Cloudflare has made Encrypted Client Hello (ECH) available across all plans, marking the end of a years-long effort to eliminate the one remaining piece of metadata that leaks website destinations during a TLS connection. ECH, which is documented in a proposed IETF standard, is the successor to the earlier Encrypted SNI (ESNI) initiative and hides the Server Name Indication (SNI) sent during the TLS handshake.

With ECH enabled, an intermediary observing traffic between a user and a Cloudflare-hosted site can see only that the connection targets Cloudflare’s shared ECH front-end domain — not the specific website being requested.

Why SNI was the last plaintext leak

Early web traffic was transmitted in plaintext, meaning any network hop between browser and server could read request contents and destinations. The introduction of SSL and later TLS protected the actual content of sessions, but that protection has never been complete. Even with encrypted traffic, two metadata channels routinely expose user intent: the DNS lookup and the SNI field.

DNS requests, by default unencrypted, reveal which hostname a client is resolving. Cloudflare addressed that with DNS over HTTPS (DoH) in 2019 and later with Oblivious DNS over HTTPS (ODoH), which prevents even the DNS resolver from correlating a user with the names they query.

That left SNI. During a TLS handshake, the first message sent by the client is a ClientHello containing the ciphers and TLS version it supports as well as the SNI. Because encryption has not yet been established, the SNI must travel in plaintext so the server can select the right certificate:

BLOG-2055 Embedded Image - oMmWOR

Any party along the network path can therefore identify the destination by inspecting that first packet. ECH removes that visibility.

Splitting the ClientHello

ECH works by dividing the ClientHello into a plaintext outer portion and an encrypted inner portion:

  • Outer ClientHello carries non-sensitive connection parameters, such as supported ciphers and TLS version, along with a public “outer SNI” shared by all ECH-enabled sites on Cloudflare.
  • Inner ClientHello is encrypted with a public key and holds the real target hostname — the “inner SNI” — which only the destination server can read.

Cloudflare has designated cloudflare-ech.com as the common front-end name. Since the company controls that domain, it holds the certificates required to complete a TLS handshake for it. From the perspective of an on-path observer, every connection to an ECH-enabled site on Cloudflare appears as a standard handshake toward this single domain:

BLOG-2055 Embedded Image - 89bLyl

To a network observer, the handshake for any Cloudflare customer site is indistinguishable from any other. The user’s destination is hidden, and once the handshake completes, the session proceeds normally.

Availability and rollout

ECH is already live for all free Cloudflare zones. Paying customers can request the feature from the Cloudflare dashboard, and Cloudflare states it will enable ECH for new sign-ups over the following weeks.

Browser support is building momentum: both Google Chrome and Firefox are moving toward ECH support. The broader concern is adoption beyond Cloudflare’s own network. ECH only provides meaningful privacy when the set of hosts sharing a front-end SNI is large; a wider deployment base across multiple providers makes it harder for any observer to infer destinations from traffic patterns alone.

More technical detail is available in Cloudflare’s introductory ECH blog post and its developer documentation.