Encrypted Client Hello (ECH): How Modern TLS Protects SNI and Enhances Privacy

For decades, the Transport Layer Security (TLS) protocol has served as the backbone of secure internet communication. Whenever you visit an HTTPS website, TLS ensures that your connection is encrypted, preventing local eavesdroppers from reading form inputs, passwords, or session tokens. However, despite decades of cryptographic refinements that culminated in the TLS 1.3 standard, a glaring privacy vulnerability remained at the very beginning of every connection: the plaintext Server Name Indication (SNI).

The introduction of Encrypted Client Hello (ECH), developed within the Internet Engineering Task Force (IETF), finally eliminates this fundamental privacy gap. By encrypting the server identity during the initial cryptographic handshake, ECH transforms how modern web browsers interact with hosting platforms, Content Delivery Networks (CDNs), and intermediate network monitoring middleboxes.

The Historic Privacy Flaw: Plaintext Server Name Indication

To appreciate the architectural significance of ECH, one must examine how web servers host multiple domains. In the early days of the web, each secure website required a dedicated public IPv4 address because a server had to select its digital certificate before receiving an encrypted HTTP request. As IPv4 address exhaustion accelerated, TLS introduced the SNI extension in RFC 3546.

SNI allowed client browsers to state the destination hostname inside the very first message of the connection—the ClientHello. The destination web server could inspect this field and serve the correct TLS certificate for that specific domain. However, because this exchange happens before encryption keys are established:

1. Cleartext Metadata Broadcast: The exact domain name you visit travels across local Wi-Fi networks, Internet Service Provider routers, and national transit hubs in cleartext.
2. Selective Network Shaping and Filtering: Network appliances and Deep Packet Inspection (DPI) firewalls read this unencrypted SNI field to catalog user habits, compile advertising profiles, or drop connection handshakes matching targeted domains.
3. Incomplete Cryptographic Isolation: Even when DNS queries are secured using DNS over HTTPS (DoH), observing middleboxes can reconstruct an individual's entire web browsing history simply by sniffing SNI headers.

How Encrypted Client Hello Works Under the Hood

Encrypted Client Hello solves this exposure by bifurcating the initial handshake into two separate structures: an outer ClientHelloOuter and an inner ClientHelloInner.

1. Key Distribution via DNS HTTPS Records

Before a client can send an encrypted message to a server it has not yet connected to, it requires the destination server's public encryption key. ECH leverages modern DNS infrastructure by querying specialized HTTPS or SVCB DNS resource records (defined in RFC 9460).

When your browser resolves a domain name, the authoritative DNS server returns not only the destination IP address but also an echconfig payload containing the server public key and supported cryptographic cipher suites (typically using Hybrid Public Key Encryption, or HPKE).

2. Dual Handshake Architecture

Armed with the server public key, the client browser constructs two distinct handshakes:

• ClientHelloOuter: A public, sacrificial handshake visible to intermediate routing middleboxes. It contains benign metadata and a generic front-facing server name (such as cloudflare.com or fastly.net), ensuring compatibility across strict legacy network equipment.
• ClientHelloInner: The genuine handshake containing the real destination hostname (such as private-forum.example.org), encrypted using HPKE with the server public key.

The client embeds this encrypted inner handshake as an extension inside the outer handshake. When an edge gateway receives the packet, it decrypts the inner payload using its private key, smoothly routes the connection to the intended application backend, and completes the TLS 1.3 handshake. Intermediate eavesdroppers observe only the outer, generic CDN domain.

Protocol Comparison: Traditional TLS vs Encrypted Client Hello

The architectural differences across cryptographic handshake generations illustrate the evolution of connection privacy:

Why ECH and VPNRice Provide Complementary Protection

While Encrypted Client Hello represents a historic leap forward for web encryption, it does not replace the comprehensive security provided by a robust virtual private network.

First, ECH only protects protocols running on top of TLS (primarily web traffic). Background operating system processes, gaming telemetry, Voice-over-IP (VoIP) streams, and non-HTTPS applications continue to expose routing destinations. Second, intermediate network operators still observe destination IP addresses; if a website operates on a dedicated IP without a shared CDN front, routing metadata remains vulnerable to traffic analysis.

When you route your device traffic through VPNRice, your entire operating system connection is encapsulated inside an encrypted tunnel, hiding destination IP addresses and replacing your network footprint with high-reputation server nodes. Operating with ECH enabled inside this tunnel delivers layered defense: local networks cannot see target IPs or protocols, and transit backbones cannot extract hostnames.

To audit your current browser connection headers and examine whether your public IP exposes geolocation identifiers, check our free What is my IP diagnostic tool. To verify whether your system prevents address leaks during real-time peer exchanges, use our WebRTC Leak Test utility.

Get VPNRice.