What ECH and Oblivious DNS Can—and Cannot—Hide

Behavioral defenses change what a local research agent does. Protocol defenses change what a network observer can identify while that work is happening. This chapter compares two mechanisms that protect different layers: TLS Encrypted ClientHello, or ECH, hides sensitive fields in a TLS handshake; Oblivious DNS over HTTPS, or Oblivious DoH, separates a client's network origin from the plaintext DNS query. The practical value is not a promise that either mechanism makes a WRA invisible. It is a precise way to ask which observer loses which signal.

That distinction matters because the WRA study's baseline assumes that DNS and TLS handshake metadata remain visible. ECH and Oblivious DoH address parts of that baseline, but the selected sources do not measure a WRA deployed with both mechanisms. The protocol specifications state goals, message flows, and assumptions. The study measures prompt and trait inference under a different visibility model. A sound conclusion must keep those evidence types separate.

ECH protects the inner handshake, not the whole research session

In ordinary TLS 1.3, much of the handshake is encrypted, but the Server Name Indication, or SNI, has traditionally been exposed in the ClientHello. SNI tells an on-path observer which server name the client is trying to reach. For a research agent visiting many domains, that direct name can be a valuable feature in the same trace that the study uses for prompt inference.

ECH changes the handshake structure. The client constructs a private ClientHelloInner containing sensitive values such as the true server name and potentially the application-protocol list. It then places an encrypted form of that inner message inside a visible ClientHelloOuter. The outer message carries innocuous values and identifies a client-facing service rather than exposing the backend name. The client-facing server uses the ECH configuration and its private key to decrypt the inner hello and either handles the connection itself or forwards it to a backend.

The specification describes two deployment topologies. In shared mode, the client-facing provider is also the origin server for the domains that point to it. In split mode, a client-facing server receives the outer connection and relays the protected connection to a backend origin that terminates TLS. The client-facing and backend servers are separate roles in the latter arrangement. This division can hide the backend origin from the party that accepts the outer connection, but it introduces coordination and correlation requirements between the two sides.

ECH's privacy goal is an anonymity set. Connections to server names behind the same client-facing service should look alike enough that a passive observer cannot identify which backend name terminated the connection. The size and quality of that set depend on deployment. If each name uses a distinct ECH configuration, the set can effectively have one member. If many names share a configuration and keep externally visible handshake behavior consistent, the set is stronger. Configuration identifiers, different cipher or extension behavior, message lengths, and other public differences can make members distinguishable.

The configuration itself also creates a dependency on DNS and deployment state. Domains publish or otherwise provision an ECH configuration containing a public key and related metadata. Clients use it to encrypt the inner hello.