RFC 9849: TLS Encrypted Client Hello

The Internet Engineering Task Force has published RFC 9849, standardizing the Encrypted Client Hello (ECH) extension for TLS 1.3 and DTLS 1.3. This mechanism allows clients to encrypt their ClientHello messages using a server's public key, protecting sensitive information like the Server Name Indication (SNI) from network observers.

The SNI extension, which reveals the target domain for a connection, has long been a privacy concern in TLS. While TLS 1.3 encrypts most of the handshake, the plaintext SNI remains visible to anyone monitoring the network. ECH addresses this by allowing clients to send an encrypted version of their ClientHello that only the intended server can decrypt.

How ECH Works

ECH operates in two modes:

• Shared Mode: The client-facing server is also the origin server for all domains it hosts
• Split Mode: The client-facing server acts as a proxy, forwarding the decrypted ClientHello to the actual backend server

To use ECH, a client first obtains an ECH configuration from DNS records. This configuration contains:

• An HPKE public key for encrypting the ClientHello
• Metadata including the maximum server name length and public server name
• Supported cipher suites

When connecting, the client creates two ClientHello messages:

1. ClientHelloInner: The real ClientHello with sensitive information
2. ClientHelloOuter: A public ClientHello containing the encrypted ClientHelloInner

The server then attempts to decrypt the extension. If successful, it forwards the decrypted ClientHelloInner to the backend server. If decryption fails, the server rejects ECH and proceeds with the plaintext ClientHelloOuter.

Privacy Benefits

ECH provides several privacy improvements:

• Handshake Privacy: Connections to servers within the same anonymity set become indistinguishable
• Downgrade Resistance: Attackers cannot force a connection to fall back to unencrypted ClientHello
• SNI Protection: The server name and other sensitive extensions are encrypted

The anonymity set is determined by how the client-facing server configures its ECH keys. Servers should use the same ECH configuration for as many server names as possible to maximize the anonymity set size.

Deployment Considerations

ECH requires coordination between clients, client-facing servers, and backend servers. During deployment:

• Servers must support ECH before advertising it in DNS
• ECH configurations should be retained for their validity period to handle caching
• A retry mechanism allows clients to recover from misconfigurations

When ECH is rejected, clients authenticate the connection using the public name from the ECH configuration rather than the SNI. This ensures the client is talking to the expected client-facing server, though the connection isn't usable for application data.

Security Features

The specification includes several security mechanisms:

• Configuration Identifiers: Help servers quickly identify which ECH key to use
• Padding: Prevents length-based attacks by padding ClientHelloInner to multiples of 32 bytes
• GREASE Support: Allows clients to send dummy ECH extensions to avoid standing out
• Trial Decryption: Servers can attempt decryption with multiple keys when configuration IDs are ignored

Active Attack Mitigations

ECH defends against several active attacks:

• Client Reaction Attacks: Prevents attackers from learning the SNI by observing client behavior
• HelloRetryRequest Hijacking: Ensures the same HPKE context is used for both ClientHello messages
• ClientHello Malleability: Authenticates all inputs to prevent parameter manipulation
• Packet Amplification: Requires linear-time processing and prevents duplicate extension references

IANA Considerations

The RFC registers several new values:

• encrypted_client_hello extension (0xfe0d)
• ech_outer_extensions extension (0xfd00)
• ech_required alert (121)
• A new ECH Configuration Extension registry

Looking Forward

ECH represents a significant step forward in TLS privacy. By encrypting the ClientHello, it closes a long-standing privacy gap in TLS 1.3. The specification is designed to be deployable incrementally, with a fallback mechanism for when ECH isn't supported.

However, ECH is not a complete privacy solution. It requires encrypted DNS for full effectiveness, and other channels like plaintext client DNS queries or visible server IP addresses may still leak information. Nevertheless, ECH provides a practical mechanism for protecting the SNI and other sensitive ClientHello information from network observers.

RFC 9849: TLS Encrypted Client Hello