--- title: Encrypted Client Hello (ECH) url: https://www.emergentmind.com/topics/encrypted-client-hello-ech type: topic --- # Encrypted Client Hello (ECH) Encrypted Client Hello (ECH) is an IETF-proposed extension to TLS 1.3 designed to encrypt privacy-sensitive handshake metadata, particularly the Server Name Indication (SNI) and protocol negotiation parameters such as ALPN, within the ClientHello message. ECH addresses fundamental privacy weaknesses of earlier TLS versions, where SNI and ALPN are transmitted in cleartext, and provides a standardized cryptographic mechanism for their protection. ECH achieves this by encapsulating an “inner” ClientHello with the true SNI within an “outer” ClientHello with innocuous parameters, encrypting the inner payload under a public key obtained via DNS SVCB or HTTPS resource records. This architecture aims to eliminate passive SNI-based traffic analysis, strengthen privacy against network observers, and enable a more robust delivery of privacy guarantees by leveraging broad DNS and TLS infrastructure support [2309.10344], [2207.01841]. ## 1. Protocol Structure and Cryptographic Mechanisms ECH modifies the TLS 1.3 handshake by splitting the ClientHello into two layers. The outer ClientHello contains non-sensitive parameters such as a “dummy” SNI and minimal ALPN options, and introduces a new `encrypted_client_hello` extension. This extension’s payload is constructed by encrypting the true, full-featured inner ClientHello using Hybrid Public Key Encryption (HPKE, RFC 9180), with a public key discovered through DNS. The typical cryptographic workflow is as follows: - The client fetches SVCB or HTTPS DNS records for the target domain, parsing out the ECHConfigList, which encodes one or more ECHConfig structures containing the HPKE public key and cryptographic suite information. - The client chooses an ephemeral HPKE keypair, computes $(\mathrm{enc}, \mathrm{shared\_secret}) \gets \mathrm{HPKE.Encap}(PK_\mathrm{ech}, pk_\mathrm{ecdh})$. - Using HKDF, the client derives symmetric AEAD keys and nonces for payload encryption: - $\mathrm{secret}_0 = \mathrm{HKDF\text{-}Extract}(0, \mathrm{shared\_secret})$ - $\mathrm{secret}_1 = \mathrm{HKDF\text{-}Expand}(\mathrm{secret}_0, "tls13~ech~key", L_1)$ - $\mathrm{secret}_2 = \mathrm{HKDF\text{-}Expand}(\mathrm{secret}_1, "tls13~ech~nonce", L_2)$ - The inner ClientHello is encrypted with AEAD under $(\mathrm{secret}_1, \mathrm{secret}_2)$, with additional data derived from the outer ClientHello. The result (enc, ciphertext) is placed as the ECH extension. - The fronting server, which possesses the private key $sk_\mathrm{ech}$, decapsulates the shared secret, reverses the HKDF chain, and decrypts the inner ClientHello, resuming a standard TLS 1.3 handshake [2207.01841]. This multiplexing of true and decoy ClientHello messages provides indistinguishability of connections within an “anonymity set”, ensuring that only legitimate endpoints recover handshake metadata. ## 2. ECH Discovery and Configuration via DNS SVCB/HTTPS Records Implementation of ECH is closely tied to the development of DNS SVCB (type 64) and HTTPS (type 65) resource records as standardized in draft-ietf-dnsop-svcb-https-12. In service mode (priority > 0), these records convey endpoint metadata and SvcParams, a set of extensible key–value pairs encoding service properties. - ECH configuration is identified by SvcParamKey 0x0008 (“ech”), which holds a base64-encoded ECHConfigList following the TLS ECH draft specification (draft-ietf-tls-esni-16). The presentation syntax is: ``` HTTPS 1 IN SVCB 0 ech="" alpn="h3,h2" ``` - The ECHConfigList’s wire format—$(2\,\mathrm{bytes}\,\mathrm{length}) || \text{ECHConfig}_1 || \text{ECHConfig}_2 \ldots $—includes cryptographic parameters such as KEM, KDF, AEAD algorithm identifiers, public keys, maximum name length, and extension blocks. The ech SvcParam carries binary data, base64-encoded for DNS transport and parsing consistency. The client’s TLS stack consumes the DNS-resolved ECHConfig for key derivation and selects the appropriate ECHConfig by matching protocol version and cryptographic capabilities [2309.10344]. ## 3. Deployment and Empirical Observations Large-scale Internet scans performed by Johannes Zirngibl et al. in February–March 2023 revealed the status of ECH and related SVCB/HTTPS deployments: | Record Type | Domains with Record | Ech SvcParam Present | Operator (ech records) | |---------------------|--------------------|----------------------|-------------------------| | SVCB (type 64) | ~3.96K | 0 | - | | HTTPS (type 65) | ~10.56K | 20 | Cloudflare (AS13335/209242)| - Only 20 HTTPS-mode records (0.02%) were observed to carry the ech SvcParam, all hosted by Cloudflare’s authoritative nameservers. No other operators advertised ECH in SVCB/HTTPS records as of March 2023 [2309.10344]. - The IETF DNSOP draft temporarily removed the ech parameter to permit finalization of the SVCB/HTTPS RFC, with the intent to reintroduce it upon ECH’s stabilization as an RFC. - The vast majority of SVCB/HTTPS records in the wild at the time encoded ALPN and IP address hints, signifying an early deployment phase for advanced privacy features. *This suggests* that active ECH configuration delivery through DNS remains nascent but likely to accelerate as service providers update their infrastructure and DNS records. ## 4. Privacy, Threat Model, and Limitations ECH was explicitly designed to prevent leakage of handshake metadata to passive observers, such as ISPs or censorship middleboxes, by encrypting the SNI and ALPN in transit. ECH’s security goals include: - Confidentiality: Hiding all handshake parameters inside the ClientHello from any eavesdropper lacking the server’s ECH private key. - Indistinguishability: ECH connections within an anonymity set are externally indistinguishable based on handshake characteristics. - Robustness: Building on TLS 1.3’s downgrade prevention and message authentication mechanisms, including MAC-based integrity checks for decryption failures [2207.01841]. However, ECH’s protections are limited when ancillary “side-channel” connections—e.g., for ads, metrics, control APIs—use legacy TLS (e.g., 1.2). In real deployments, as many major services use TLS 1.3 + ECH only on primary channels, but side-channels remain on TLS 1.2, an observer can correlate side-channel SNI to re-identify the main ECH-protected flow and thus defeat endpoint privacy. The effectiveness of ECH depends on consistency across all service channels [2207.01841]. ## 5. Operational Considerations and Best Practices Domain operators seeking to deploy ECH should adhere to recommendations to maximize privacy assurance and compatibility: - Deploy SVCB/HTTPS in service mode (priority > 0) to fully advertise all relevant parameters (ALPN, IP hints, port), and verify advertised metadata against live server configurations. - Upon ECH standardization, repopulate SvcParam 0x0008 with a correct, base64-encoded ECHConfigList, offering one ECHConfig per active public key to support rotations. - Use the “mandatory” SvcParam judiciously; enforcing strict ECH parameter requirements causes handshake failures for legacy clients. - Prefer DNS authorities and hosting services (Cloudflare, NS1, Akamai, etc.) that support SVCB/HTTPS RRs, and monitor application-layer behavior via automated scans to ensure correct alignment of DNS and endpoint properties. A significant empirical finding: in a cluster of ~23 Cloudflare-hosted domains with HTTP/3 claims, QUIC handshake timeouts were found due to “I’m Under Attack” mode, highlighting the need for end-to-end validation of DNS metadata and service behavior [2309.10344]. ## 6. Performance, Compatibility, and Outstanding Research Problems While ECH introduces additional computational steps—particularly HPKE encapsulation and AEAD encryption—these are estimated to add no more than microseconds of processing overhead per handshake on modern CPUs. DNS lookup latency for the SVCB/HTTPS record may be amortized via caching. Overall, this performance cost is minimal relative to the privacy benefit. TLS 1.3’s reduced handshake round-trips (compared to TLS 1.2) further mitigate total connection setup time [2207.01841]. Compatibility barriers persist: - ECH requires both client and server to implement HPKE and the ECH ClientHello extension. - Partial deployment, especially when side-channels use TLS 1.2, undermines privacy goals. - Retrofitting ECH onto legacy TLS (1.2 and earlier) without two-phase handshakes is an open challenge, as is the coordination of unified PKI and key-distribution strategies across fronting infrastructures and CDNs. Open research directions include: - Mechanisms for extending ECH protection to legacy protocols. - Automated key distribution and configuration through DNS, with resolver cooperation. - Assessing real-world ECH performance under mobile and resource-constrained environments. - Developing validation and analytics tools that do not themselves reintroduce SNI exposure [2207.01841]. In summary, while ECH and DNS-integrated configuration via SVCB/HTTPS RRs demonstrate a promising path toward end-to-end privacy for Internet services, the realization of uniform handshake metadata confidentiality requires ubiquitous deployment across all application and supporting channels, rigorous configuration validation, and continued innovation in TLS protocol design and deployment methodologies [2309.10344], [2207.01841]. Source: https://www.emergentmind.com/topics/encrypted-client-hello-ech