Wiki · Concept · Last reviewed June 25, 2026

Encrypted Client Hello

Encrypted Client Hello, or ECH, is RFC 9849's TLS extension for encrypting sensitive ClientHello fields, including the true server name, inside a deployment-defined anonymity set.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: TLS, ECH, SNI, DNS, privacy, agents, metadata, surveillance

Definition

Encrypted Client Hello is defined by RFC 9849, published in March 2026 as an Internet Standards Track RFC. It extends TLS so a client can encrypt a private ClientHello for a client-facing server while sending an outer ClientHello that remains visible enough for routing and compatibility.

The problem is not ordinary TLS content encryption. RFC 8446 already defines TLS 1.3 as a protocol designed to prevent eavesdropping, tampering, and message forgery. The remaining metadata problem is that the TLS ClientHello can expose the target server name through Server Name Indication, or SNI, and can expose other sensitive preferences such as the Application-Layer Protocol Negotiation list.

Mechanism

RFC 9849 describes an inner and outer split. The client constructs a private ClientHelloInner, encrypts it, and carries it in an extension in ClientHelloOuter. If the client-facing server can decrypt the extension, it proceeds with the inner ClientHello. If not, it rejects ECH and continues with the outer ClientHello path.

ECH needs configuration before the client connects. RFC 9848, also published in March 2026, defines bootstrapping through DNS Service Bindings. It conveys ECH configuration through the ech SvcParam in SVCB or HTTPS resource records. RFC 9460 supplies the underlying SVCB and HTTPS record framework for publishing alternative service endpoints and parameters through DNS.

RFC 9848 also changes fallback expectations. If all alternative endpoints have an ech parameter, an ECH-capable client that would otherwise treat SVCB as optional must switch to SVCB-reliant connection establishment after successful SVCB resolution, because direct fallback would erase the privacy benefit.

Privacy Boundary

ECH protects selected handshake metadata from passive observers. Its central privacy goal is that connection establishment to one server name inside an anonymity set is indistinguishable from connection establishment to another server name in that same set. The size and usefulness of the set depend on client-facing server configuration.

The boundary is narrower than the slogan. ECH does not hide the client IP address, the server IP address, packet timing, traffic volume, account identifiers, cookies, application logs, or destination knowledge held by the resolver. RFC 9849 says ECH is less useful when DNS queries in transit are not encrypted, and RFC 9848 says the specification does not conceal the server name from the DNS resolver.

Agent Context

Agent systems make ECH important because automated browsing and tool use can contact many hosts before a human understands the whole chain. A browser agent may fetch a page, follow embedded resources, call an identity provider, load an API endpoint, or test a package host. Without ECH, the TLS handshake can expose some of that destination intent even if the later HTTP exchange is encrypted.

ECH also changes observability. Enterprise firewalls, secure web gateways, malware sandboxes, and compliance monitors often depend on SNI visibility. If ECH is enabled, governance has to move toward endpoint logs, resolver policy, explicit tool allowlists, certificate and destination inventories, and auditable agent traces rather than assuming the network path will reveal each hostname.

Governance Use

A governed ECH deployment should record the client-facing provider, public name, anonymity-set assumptions, DNS publication path, SVCB or HTTPS records, ECHConfig rotation, fallback behavior, resolver policy, and whether DNS transport is encrypted. For agents, record whether ECH is controlled by the browser, operating system, runtime, remote workspace, proxy, or enterprise policy.

Auditors should also record where hostname visibility reappears. A hostname hidden from a passive on-path observer may still appear in DNS logs, proxy logs, browser history, endpoint telemetry, model tool traces, access-control decisions, and application-side analytics.

Limits

ECH is not anonymity, safe browsing, consent, bot authorization, malware detection, or proof that an agent should reach a host. It is a TLS handshake privacy mechanism. It reduces one metadata leak while leaving many other network, DNS, account, and application surfaces intact.

ECH can also fail or be downgraded by configuration and deployment choices. Mixed SVCB records with some ECH-capable endpoints and some non-ECH endpoints are vulnerable to downgrade pressure. A client-facing server with only one private name in its anonymity set gives little practical cover.

Source Discipline

Claims about ECH status, ClientHelloInner, ClientHelloOuter, SNI protection, ALPN privacy, anonymity sets, and related privacy leaks should cite RFC 9849. Claims about DNS bootstrapping, ech SvcParams, SVCB-reliant fallback, and resolver leakage should cite RFC 9848. Claims about SVCB and HTTPS resource records should cite RFC 9460. Claims about TLS 1.3 should cite RFC 8446.

Spiralist Reading

Spiralism reads ECH as a change in who gets to watch the moment of approach. The page request may still happen, the account may still identify the user, and the resolver may still know the name. But the first visible gesture is no longer automatically a public confession to every observer on the path.

For agents, that is both privacy and responsibility. If hostname visibility disappears from the middle of the network, institutions need clearer records at the edges: what the agent intended, who authorized it, which resolver saw it, and where the trail is kept.

Sources

Return to Wiki