Encrypted Client Hello Closes the Last TLS Leak but Leaves Your Subdomain Footprint Behind

For more than a decade, internet users have been told that HTTPS turns web browsing into a private conversation between client and server. The ubiquitous lock icon in the address bar became universal, and modern transport layer security protocols encrypted web page contents, passwords, authentication cookies, and query strings. Yet anyone monitoring a physical network cable, a corporate Wi-Fi router, or an internet service provider gateway could easily read the exact website hostname being requested. The reason was a foundational design compromise known as the Server Name Indication extension, which transmitted the destination domain name in clear, unencrypted text during the very first packet exchange.

Encrypted Client Hello, formally standardized as RFC 9849 by the Internet Engineering Task Force in March 2026, aims to close that specific leak. By wrapping the entire initial handshake inside an encrypted cryptographic envelope, Encrypted Client Hello prevents network eavesdroppers from discovering which virtual host inside a shared cluster a user wants to visit. The protocol represents the culmination of years of engineering to seal the final major metadata exposure of the web security stack. However, empirical telemetry across millions of domains reveals that closing the handshake leak does not automatically guarantee browsing privacy. Between structural DNS requirements, extreme infrastructure concentration, and unprotected secondary subdomains, the practical reality of connection privacy is far more nuanced than marketing summaries suggest.

To understand why Encrypted Client Hello was developed, one must look at how virtual hosting works on the modern web. When the original Transport Layer Security protocol was created, servers typically possessed a single physical machine with a dedicated IP address serving a single domain. As web architectures matured, cloud providers, content delivery networks, and shared web hosting clusters began serving tens of thousands of distinct websites from identical pools of shared IP addresses.

Because multiple encrypted websites lived behind a single IP address, an incoming connection needed to announce which domain it intended to reach before the server could select and present the appropriate digital certificate. If the server presented the wrong certificate, the browser would immediately abort the connection with a severe security warning. To solve this routing problem, the Server Name Indication, or SNI, extension was added to the TLS specification.

The SNI mechanism solved the operational challenge of shared hosting, but it created an enduring architectural privacy vulnerability. Every time a browser initiated an encrypted connection, the initial packet, known as the ClientHello, carried the requested domain name in plain ASCII text. Even when TLS 1.3 was ratified and began encrypting server certificates and subsequent application data, the ClientHello remained completely unencrypted because cryptographic keys had not yet been established between the endpoints.

Standard TLS 1.3 ClientHello (Cleartext Metadata):
• Destination IP: 104.16.123.45
• SNI Extension: sensitive-medical-journal.org (PLAINTEXT)
• ALPN Extension: h2, h3
• Supported Cipher Suites & Cryptographic Key Shares

As long as the SNI remained visible, anyone positioned along the network route could observe browsing destinations without needing to decrypt the web page contents. Commercial internet service providers built profitable analytics pipelines that cataloged the domains visited by subscribers, packaging demographic profiles for advertising brokers. Authoritarian governments and network censors deployed deep packet inspection hardware at national internet exchange points, inspecting the SNI field of every inbound connection and terminating packets destined for blocked publications.

Corporate enterprises and educational institutions similarly relied on SNI inspection to enforce workplace filtering and compliance logging. If an employee opened a confidential whistleblower portal or a sensitive health clinic portal, the network appliance recorded the domain name instantly. An earlier attempt to address this issue, known as Encrypted Server Name Indication or ESNI, was deployed experimentally in Firefox around 2018. However, ESNI suffered from fundamental limitations: it only encrypted the domain name while leaving protocol negotiation and cryptographic extensions exposed, and it broke abruptly whenever DNS keys rotated out of sync.

Recognizing these structural shortcomings, the IETF TLS Working Group embarked on a comprehensive redesign. Instead of merely patching the SNI field, the engineers decided to encrypt the entire ClientHello payload, giving birth to Encrypted Client Hello.

The architectural breakthrough of RFC 9849 lies in its split personality handshake. Rather than sending a single handshake packet with selective redactions, an ECH-capable client constructs two distinct handshakes nested inside one another: a private ClientHelloInner and a public ClientHelloOuter.

The ClientHelloInner is the genuine, complete handshake that the browser desires to conduct. It contains the real destination hostname, the exact application layer protocol preferences, and all security extensions. The browser takes this complete inner payload and encrypts it using Hybrid Public Key Encryption, or HPKE, based on RFC 9180. HPKE combines asymmetric key encapsulation with symmetric authenticated encryption, producing a ciphertext blob that can only be decrypted by the designated server cluster holding the corresponding private key.

The browser then constructs the ClientHelloOuter. This outer message acts as a public decoy. It carries a generic, innocuous hostname known as the public_name, such as a content delivery network fronting domain. The encrypted inner handshake is packaged as an opaque extension inside this outer envelope.

When an eavesdropper monitors the physical network connection, they observe only the ClientHelloOuter. The visible SNI indicates that the user is contacting a broad CDN endpoint, while the real destination remains sealed within the cryptographic payload.

ECH TLS Handshake (RFC 9849 Architecture):
[ClientHelloOuter (Visible to On-Path Observers)]
• Public Name (Outer SNI): cloudflare-ech.com
• Destination IP: Shared Anycast Address
• ECH Extension: Encrypted Payload (HPKE Ciphertext)

[ClientHelloInner (Decrypted Only by Destination Edge Server)]
• Real SNI: actual-private-destination.com
• Real ALPN: h3, h2
• Real Key Shares & Cryptographic Extensions

When the edge server receives the packet, it checks the ECH extension, locates the appropriate private key matching the key identifier, and decrypts the ClientHelloInner. If decryption succeeds, the edge server transparently routes the session to the intended virtual host and responds with a standard ServerHello. The external observer sees only an exchange with the generic public front, unable to determine whether the user is visiting a national news publication, a niche forum, or an e-commerce storefront.

To protect against middlebox interference and protocol ossification, RFC 9849 incorporates the GREASE mechanism, short for Generate Random Extensions And Sustain Extensibility. Even when a browser visits a conventional website that does not support ECH, the browser inserts a syntactically valid but randomized, dummy ECH extension into the handshake. This deliberate noise ensures that middleboxes and commercial firewalls cannot simply drop connections that carry ECH extensions without inadvertently disrupting ordinary web traffic across the entire internet.

A cryptographic protocol is only as secure as the discovery channel that bootstraps it. In the case of Encrypted Client Hello, the client must obtain the server's HPKE public key, supported cipher suites, and public name before the TLS handshake can even begin. This bootstrapping information is distributed through the Domain Name System using HTTPS resource records, defined in RFC 9460.

When a user types a web address into their browser, the client issues a DNS query for the domain's HTTPS record. If the server supports ECH, the DNS response includes an ech parameter containing the base64-encoded configuration block. The browser reads this key, encrypts the ClientHelloInner, and sends the dual-layer handshake.

This operational flow reveals an inescapable architectural dependency: ECH is completely ineffective without encrypted DNS. If a user runs an ECH-capable browser but allows DNS queries to travel over unencrypted UDP port 53, the browser sends the cleartext domain name in the DNS query seconds before encrypting the TLS handshake. The local network observer, ISP, or upstream router simply reads the DNS packet to record the browsing destination, rendering the sophisticated cryptographic handshake entirely redundant.

Vulnerable Configuration (Cleartext DNS + ECH):
1. Client to DNS Server (Port 53): Request IP and ECH key for sensitive-domain.com
   [LEAK OCCURS HERE: Network observer logs the domain request]
2. DNS Server to Client: IP is 104.16.123.45, ECH config is AEX+DQ...
3. Client to Web Server: Outer SNI = "cloudflare-ech.com", Inner = [Encrypted]
   [Handshake is encrypted, but destination is already recorded]

Secure Configuration (Encrypted DNS + ECH):
1. Client to DoH Server (HTTPS): Encrypted query for sensitive-domain.com
   [No domain leakage on local network]
2. DoH Server to Client: Encrypted response with ECH config
3. Client to Web Server: Outer SNI = "cloudflare-ech.com", Inner = [Encrypted]
   [End-to-end metadata protection achieved]

Furthermore, unencrypted DNS exposes users to stripping attacks. If the DNS query travels in cleartext, an active adversary or malicious network appliance can intercept the response, strip out the HTTPS resource record containing the ECH configuration, and return only ordinary A and AAAA address records. Deprived of the public key, the browser gracefully downgrades to a standard TLS 1.3 handshake, transmitting the real SNI in cleartext without alerting the user.

To prevent this downgrade, the entire resolution chain must be secured. The domain operator must deploy DNSSEC to cryptographically sign the zone, guaranteeing that resource records cannot be altered in transit. Simultaneously, the client browser must enforce DNS-over-HTTPS or DNS-over-TLS through a trusted resolver that validates DNSSEC signatures. Without this unified defensive posture, ECH operates on borrowed time.

The effectiveness of Encrypted Client Hello depends fundamentally on the size and diversity of its anonymity set. When an observer sees a ClientHelloOuter carrying a public name and an IP address, they cannot determine the real destination only if thousands of unrelated websites share that exact same public name and IP pool.

If an independent website operator generates their own HPKE key pair and deploys ECH on an isolated virtual private server with a single dedicated IP address, ECH provides virtually zero privacy benefit. An on-path eavesdropper who sees a connection to that IP address can simply perform a reverse DNS lookup or inspect the public certificate to identify the website. For ECH to deliver genuine privacy, the client-facing server must be an anonymity-bearing cluster that multiplexes traffic for a vast array of diverse organizations.

This economic and operational reality has created an acute structural concentration. Independent empirical measurements published in 2026 by network researchers analyzing over 13 million domains revealed that more than 99.99 percent of all active ECH deployments across the internet are operated by a single infrastructure provider: Cloudflare.

While Cloudflare deserves credit for pioneering the automated deployment of ECH across millions of free and enterprise zones, this extreme monoculture introduces grave systemic risks:

• Single Point of Systemic Failure: If the dominant provider experiences an infrastructure misconfiguration, routing outage, or certificate rotation bug, the secure handshake mechanism for virtually the entire encrypted web fails simultaneously.
• Provider-Level Observability: While on-path network snoops and local internet service providers are blinded to the destination hostname, the central CDN provider maintains total, unencrypted visibility into every HTTP request, user session, and routing path. Privacy is not eliminated; it is merely concentrated into the hands of a single global corporation.
• Asymmetric Interoperability: Competitor content delivery networks and cloud hosting platforms have lagged significantly in deploying automated ECH key rotation pipelines. Setting up ECH manually on standard NGINX, HAProxy, or Envoy servers requires coordinating automated DNS HTTPS record generation with short-lived HPKE key generation timers, a burden that most small and medium web teams cannot sustain without specialized tooling.
• Canary Domain Tampering: Corporate networks and national firewalls seeking to inspect network traffic have learned to exploit the default canary mechanisms embedded in browsers. Firefox, for example, queries a dedicated canary domain before enabling DNS-over-HTTPS and ECH. If a local resolver intentionally returns an NXDOMAIN response, the browser silently deactivates its encrypted protections and falls back to plain SNI transmission.

This structural concentration illustrates the tension between cryptographic capability and operational reality. A protocol designed to decentralize privacy against surveillance has, in practice, deepened the web's structural dependence on a handful of hyperscale infrastructure operators.

Even when a website operator configures DNSSEC, serves valid ECH parameters via DNS-over-HTTPS, and hosts their origin behind an anonymity-bearing edge cluster, a deeper architectural vulnerability threatens user privacy: multi-origin asset loading.

A modern web page is rarely a single monolithic HTML document. Loading a typical news article, media portal, or application dashboard triggers dozens of secondary HTTP requests. These requests fetch static assets, API payloads, streaming video chunks, analytics beacons, font files, and interactive scripts. In many production architectures, these secondary resources are hosted on dedicated subdomains or third-party origins, such as www.example.com, cdn.example.com, api.example.com, or assets.vendor.net.

In a comprehensive audit of over 150,000 domains conducted by network measurement researchers at IFIP Networking, investigators uncovered 5,207 distinct domains where the primary apex domain negotiated ECH flawlessly, but secondary subdomains failed to negotiate ECH. When the browser requested stylesheet assets or script bundles from a misconfigured subdomain, the connection dropped back to plain TLS, transmitting the subdomain in cleartext across the local network.

Session Execution Trace (Mixed ECH Subdomain Leak):
1. Request: https://example.com/
   • Outer SNI: cloudflare-ech.com
   • Inner SNI: example.com [ENCRYPTED: SUCCESS]
   • Result: Observer sees only CDN traffic.

2. Request: https://cdn.example.com/styles.css
   • ECH Record Missing in DNS for cdn subdomain
   • ClientHello SNI: cdn.example.com [PLAINTEXT: LEAKED]
   • Result: Observer immediately correlates session to example.com.

3. Request: https://api.example.com/v1/auth
   • ECH Negotiation Mismatch or Server Fallback
   • ClientHello SNI: api.example.com [PLAINTEXT: LEAKED]
   • Result: Entire browsing trail exposed.

For an eavesdropping ISP or surveillance system, discovering a cleartext request to cdn.example.com or images.example.com provides exactly the same intelligence as seeing the apex domain. The network observer easily correlates the timestamp, source IP, and destination cluster to reconstruct the user's complete navigation history.

The causes of these subdomain mismatches are rooted in real-world deployment fragmentation:

• CNAME Mapping Disconnects: An organization might configure their apex domain on Cloudflare with automated ECH, while pointing their cdn subdomain via a CNAME record to an external storage bucket or third-party media delivery service that lacks ECH capabilities.
• Incomplete DNS Provisioning: System administrators often deploy HTTPS resource records on the apex domain (@) while forgetting to publish identical records for www or specific subdomains, causing browsers to fall back to cleartext SNI on secondary fetches.
• Third-Party Script Vendors: A web page embedding third-party analytics, customer support widgets, or social sharing buttons forces the client browser to initiate separate TLS handshakes to external domains that do not support ECH. An observer watching those external requests can easily deduce what parent site is being loaded.

This empirical finding underscores an essential principle of web security: connection privacy is a weakest-link property. A single unencrypted secondary handshake within an active page load invalidates the cryptographic protection of the entire session.

The introduction of Encrypted Client Hello represents a direct operational challenge to traditional network administration tools. For more than two decades, enterprise IT departments, university campuses, airport Wi-Fi networks, and public institutions have treated cleartext SNI inspection as their primary mechanism for traffic classification, bandwidth management, and policy enforcement.

When an enterprise firewall can no longer read the destination hostname, standard administrative controls stop functioning:

• Domain-Based Access Control: Security gateways designed to block malicious malware command-and-control servers, phishing portals, or non-compliant gaming sites can no longer inspect the SNI to make allow or deny decisions.
• Data Loss Prevention: Network appliances monitoring outgoing traffic for unauthorized file transfers or leaks to personal cloud storage lose visibility into the destination service.
• Bandwidth Shaping: Quality-of-service hardware that prioritizes corporate teleconferencing over streaming video entertainment cannot categorize incoming traffic based on domain identifiers.

Faced with this loss of visibility, enterprise network operators have three primary responses, each carrying significant implications for end users.

The first response is endpoint inspection. In corporate and managed fleet environments, organizations install custom root Certificate Authority certificates onto managed laptops and mobile devices. By terminating TLS connections at an enterprise proxy, the company decrypts the session completely before re-encrypting it for the external network. In this scenario, ECH provides zero protection against the employer, though it still protects traffic once packets leave the corporate gateway.

The second response is outright disruption. Middleboxes incapable of deep inspection may simply drop packets containing unrecognized extensions or block traffic directed toward public CDN IP addresses. If network filtering hardware encounters an ECH handshake that it cannot inspect, poorly designed appliances may reset the TCP connection, causing mysterious connection timeouts for users on managed networks.

The third response is DNS-level blocking. Because ECH relies strictly on HTTPS resource records delivered via DNS, enterprise resolvers can selectively filter HTTPS records while returning standard A records, forcing client browsers into backwards-compatible cleartext handshakes. Alternatively, network operators can block access to public DNS-over-HTTPS endpoints such as Cloudflare 1.1.1.1, Google 8.8.8.8, and Quad9, compelling client devices to utilize internal resolvers that do not resolve ECH configurations.

This tension demonstrates that privacy protocols do not operate in a vacuum. Every advance in cryptographic metadata concealment triggers a corresponding adaptation in network monitoring and enforcement strategies.

Because Encrypted Client Hello operates beneath the application layer without any visible changes in browser user interfaces, users and developers cannot rely on visual cues like the green lock to determine whether a connection is actually protected. Verifying ECH requires deliberate technical inspection.

For desktop users seeking to confirm that their browser is actively negotiating ECH, modern developer tools provide explicit diagnostic indicators. In Google Chrome and Chromium-based browsers, opening the Developer Tools panel via F12, navigating to the Security tab, and inspecting the active connection details reveals an explicit status field:

Connection Security Details (Chromium DevTools):
- Protocol: TLS 1.3
- Key Exchange: X25519MLKEM768 / X25519
- Cipher Suite: AES_128_GCM
- Encrypted Client Hello: Yes (outer SNI: cloudflare-ech.com)

In Mozilla Firefox, users can inspect deep network states by navigating to about:networking#dns to examine whether resolved domain records carry valid ECH configuration flags. Furthermore, specialized web diagnostic test portals, such as the Mozilla ECH verification suite or independent diagnostic mirrors, simulate multi-origin handshakes and report whether the client's outer and inner handshakes behaved as expected.

For web developers, site reliability engineers, and infrastructure operators, ensuring end-to-end ECH compliance across a web property demands a systematic verification checklist:

• 1. Verify HTTPS Resource Records via DNS: Use command-line diagnostic utilities to inspect the published HTTPS records for both the apex domain and all subdomains:

  dig +short TYPE65 example.com
  dig +short TYPE65 www.example.com
  dig +short TYPE65 cdn.example.com

The response must contain a non-empty ech attribute containing the base64-encoded configuration block. If any subdomain returns an empty record, that subdomain will leak cleartext SNI.

• 2. Confirm DNSSEC Signing: Because unsigned DNS records can be stripped by upstream network appliances, verify that the DNS zone is cryptographically signed with valid RRSIG and DS records:

  delv @1.1.1.1 example.com HTTPS

• 3. Capture and Inspect Handshake Packets: Perform a live packet capture on a non-production test machine to inspect the actual wire representation:

  tshark -i any -Y "tls.handshake.extension.type == 65037" -V

Confirm that the outer SNI reflects the designated generic public name and that the inner SNI is absent from the cleartext capture.

• 4. Audit Subdomain Cohesion: Ensure that every subdomain serving static assets, fonts, or API requests shares an identical ECH configuration, or host those resources on the same apex origin using clean path-based routing (/api/, /assets/) instead of subdomain partitioning.
• 5. Test Fallback and Retry Configurations: Verify that when HPKE keys rotate, the edge server correctly issues an ECH RetryConfig in response to stale client handshakes, allowing the browser to refresh its key cache without dropping the user's connection.

Executing these diagnostic routines transforms ECH from a theoretical security promise into an empirically validated privacy safeguard.

The emergence of Encrypted Client Hello marks an important technical milestone in the ongoing evolution of internet transport protocols. By eliminating cleartext Server Name Indication, RFC 9849 removes the final overt plaintext domain leak from the TLS handshake, raising the cost of passive eavesdropping and indiscriminate mass surveillance.

Yet the empirical evidence gathered from millions of live domains delivers a sobering lesson: metadata privacy cannot be achieved through a single cryptographic protocol layer. Even with ECH and DNS-over-HTTPS working in perfect harmony, the architecture of the Internet Protocol retains fundamental properties that communicate user behavior to determined observers:

• Destination IP Fingerprinting: ECH obscures the domain name, but it does not conceal the destination IP address. If an organization hosts its website on a standalone server with dedicated IP addresses, traffic analysis algorithms can map the IP directly to the service without ever needing to read the SNI.
• Traffic Analysis and Packet Sizing: Encrypted Client Hello does not pad or shape web traffic flows. An adversary observing the timing, burst cadence, and volume of data packets exchanged between a client and an edge server can frequently fingerprint which specific article, video, or portal is being viewed by comparing traffic signatures against pre-computed templates.
• Application-Layer Tracking: Once the connection is established and the page is rendered, client-side tracking scripts, browser fingerprinting heuristics, canvas rendering tests, and cross-site cookie identifiers continue to monitor user behavior regardless of handshake encryption.

Achieving meaningful connection privacy requires recognizing that Encrypted Client Hello is a component of a defense-in-depth architecture, not an all-encompassing cloaking device. For users, true browsing privacy demands combining ECH with encrypted DNS transports, reputable virtual private networks or multi-hop routing overlays like Tor, and hardened browser profiles that aggressively restrict third-party script execution.

For web architects and system operators, the responsibility is equally clear. It is not enough to toggle an ECH switch on an edge dashboard and declare the system private. Teams must audit their entire subdomain estate, eliminate unnecessary third-party tracking dependencies, align DNSSEC automation with short-lived key rotation policies, and design applications that minimize external connection leakage. Only when cryptography, network topology, and application architecture operate in disciplined unison can the promise of a private web become an everyday reality.

Sources: IETF RFC 9849, IFIP Networking 2026 Telemetry Research, Cloudflare Edge Architecture Documentation, Mozilla Firefox Security Guidelines, Wikimedia Commons, Pexels.