Encrypted ClientHello Separates Public Routing From Private TLS Identity

TLS 1.3 encrypts most handshake messages, yet a conventional connection still exposes the initial ClientHello. That message can contain Server Name Indication, allowing an on-path observer to associate a connection with a requested hostname before application traffic is protected.

Encrypted ClientHello, standardized in RFC 9849, changes that boundary. The client constructs a private ClientHelloInner containing the service-specific parameters and wraps it inside a public ClientHelloOuter. The outer message remains usable by the client-facing infrastructure, while sensitive inner fields are protected with Hybrid Public Key Encryption.

The mechanism does not make the destination network invisible. It separates the identity needed by the backend TLS service from the information that must remain visible for the connection to reach an ECH-capable front end.

Two ClientHello messages serve different trust boundaries

The inner message is the effective TLS ClientHello when ECH is accepted. It contains the server name and other parameters used to negotiate the protected connection. The outer message is an envelope that can carry less identifying values plus the encrypted_client_hello extension containing the encrypted inner representation.

This split permits multiple backend services to share externally similar client-facing infrastructure. An observer can still see the address of that infrastructure and the visible outer handshake, but the observer does not receive the private server name in plaintext merely because TLS needs an initial client message.

The privacy set therefore depends on deployment shape. RFC 9849 describes co-located servers with consistent externally visible TLS configurations and behavior as forming an anonymity set. If one backend produces distinctive observable behavior, packet sizes, extension patterns, timing, addresses, or connection handling can reduce that set even when the inner name remains encrypted.

ECH protects selected handshake information. It does not promise that all traffic analysis signals disappear.

HPKE binds the encrypted inner message to the outer envelope

ECH uses HPKE to encrypt the encoded inner ClientHello under a public key advertised in an ECH configuration. The configuration identifies the key material and supported HPKE algorithms, along with a public name used by the client-facing service.

The outer message is not simply unauthenticated padding around a protected hostname. ECH supplies a representation of ClientHelloOuter as associated data to the HPKE operation. The construction authenticates the relevant outer inputs together with the encrypted inner content.

That binding matters because some TLS parameters remain in or are derived from the outer message for transport efficiency. If an attacker could alter those values independently while preserving a valid encrypted inner message, the two views could diverge in security-relevant ways. RFC 9849’s construction constrains that malleability by authenticating the outer representation used during decryption.

The design is broader than encrypting only SNI. Earlier approaches that protect a single extension leave more room for other visible or mutable handshake parameters to expose identity or influence negotiation.

DNS carries the key configuration before TLS starts

A client cannot encrypt ClientHelloInner without an ECH public key. RFC 9848 defines bootstrap delivery through the ech parameter in HTTPS or SVCB DNS resource records. The parameter carries an ECHConfigList, allowing a service to advertise one or more usable configurations.

This creates a dependency before the first TLS message. The client needs suitable configuration material before it can construct a real ECH offer. Key rotation, DNS caching, endpoint rollout, and front-end configuration therefore intersect with TLS privacy.

The published configuration contains public material. The corresponding private key must be available to the client-facing server that is expected to decrypt the offer, or to infrastructure acting in the role defined by the deployment. Publishing a configuration whose target servers cannot process the matching private key can turn privacy configuration into connection failure.

DNS delivery also means ECH does not independently provide confidentiality for its own bootstrap record. Protecting DNS transport and authenticating DNS data are separate architectural concerns. The ECH public key is intended to be public; the security issue is whether the client receives configuration associated with the intended service and whether fallback behavior preserves the desired privacy policy.

Rejection is a retry path, not permission for silent downgrade

ECH key material rotates, and clients can hold stale configurations. A client-facing server may therefore receive an ECH offer that it cannot decrypt even though the service supports ECH with newer keys.

RFC 9849 includes an authenticated retry mechanism for this state. When ECH is rejected, the resulting connection is not used by the client for application data. The client can authenticate the public-facing endpoint and obtain retry configurations under the protocol rules, then establish a new connection with current material.

This property is central to downgrade resistance. Treating decryption failure as permission to continue ordinary application traffic with the private name exposed in a fresh plaintext SNI would let interference erase the privacy property.

RFC 9848 applies the same principle to DNS service binding behavior. When resolution successfully indicates alternatives carrying ECH configuration, an ECH-capable client cannot simply fall back to a direct connection in a way that discards ECH privacy.

Availability and privacy are coupled here by design. A deployment that insists on protected identity can prefer connection failure over a transparent downgrade that exposes the target name.

The public name is intentionally visible

An ECH configuration includes a public_name. On rejection, the client authenticates the connection for that public name rather than the private backend identity. The public name is part of the externally visible service boundary and is not intended to be hidden by ECH.

This means ECH changes the granularity of observation rather than eliminating observation. A network can often identify the client-facing provider from destination addresses, DNS behavior, or the public name. The protected property is which backend service within the relevant anonymity set the client intends to reach.

Deployments with one public name per private service gain little aggregation from that arrangement. Shared client-facing names and consistent observable behavior create a larger set in which private service selection carries less externally visible information.

The distinction also affects policy systems that historically treated plaintext SNI as a routing or filtering signal. Once the private name moves inside ECH, a passive middlebox cannot depend on seeing that value without terminating or otherwise participating in the relevant trust architecture.

Front-end and backend roles can be split

RFC 9849 supports a model in which the client-facing server and backend server are separate systems. The client-facing component processes the outer ECH message and obtains the inner ClientHello; the backend performs the TLS handshake using the inner message as the effective client input.

This division creates a new key and message-handling boundary. The ECH private key enables decryption of protected client handshake metadata, so access to that key is a privacy-sensitive capability even though it is not the same credential as a backend certificate private key.

A front end that can decrypt ECH necessarily gains visibility into the protected inner handshake. ECH protects against observers outside that role; it does not hide the target service from infrastructure authorized to perform ECH decryption.

Operational separation can still be valuable. Backend certificate keys need not be distributed merely because a front end performs ECH processing, and ECH keys can rotate on a schedule suited to privacy exposure. The exact split depends on implementation and deployment architecture.

GREASE protects protocol deployability, not service identity

Clients without a usable ECH configuration can send a GREASE ECH extension containing a syntactically plausible dummy offer. The purpose is to keep network paths tolerant of the extension and reduce ossification around assumptions that only real ECH-capable destinations carry the code point.

A GREASE offer does not create an encrypted inner service identity. It exercises the extension surface so intermediaries are less able to distinguish support based solely on whether the extension appears.

This distinction prevents an important analytical error: visible ECH-shaped bytes do not prove that a private ClientHello was successfully protected or accepted. Actual ECH security depends on possession of a compatible configuration, successful HPKE processing, server acceptance, and the client’s verification of that acceptance.

Protocol camouflage and negotiated confidentiality are separate properties.

Privacy depends on the full observable connection

Encrypting SNI closes a prominent plaintext signal, but destination addresses remain visible to ordinary IP routing. A service hosted on a unique address can therefore remain easy to identify even when its name is absent from the outer handshake.

Traffic characteristics can also separate services that nominally share a front end. Distinct ALPN behavior, connection termination patterns, response sizes, retry behavior, or other externally visible differences can reduce practical indistinguishability. RFC 9849 explicitly frames consistent externally visible TLS configuration and behavior as part of the anonymity-set model.

ECH also does not conceal application data from the TLS endpoint. After the protected handshake reaches the intended backend, that endpoint processes the connection under normal TLS trust assumptions.

The mechanism is strongest when architecture supports aggregation: shared client-facing infrastructure, consistent outer behavior, correct key distribution, and downgrade-resistant bootstrap behavior. In that environment, ECH moves private service selection behind a cryptographic boundary without requiring the network path to become oblivious to the front-end destination.

The result is a narrower and more precise privacy claim than hidden routing. ECH leaves enough public structure to establish a connection to an authorized front end while encrypting the service-specific ClientHello that the backend actually uses.