Encrypted Client Hello: Defender Visibility
Understand Encrypted Client Hello, what ECH hides, what network evidence remains, and how defenders can redesign monitoring without blocking privacy.
ECH encrypts the question the network used to read
Encrypted Client Hello defender visibility changes because the server name moves out of the plaintext TLS handshake. Traditional sensors often read the Server Name Indication field to label a connection before application data was encrypted. With ECH, that label belongs in ClientHelloInner, protected with Hybrid Public Key Encryption and carried inside ClientHelloOuter.
RFC 9849, published in March 2026, defines the standardized protocol. A domain publishes an ECH configuration containing a public key and metadata. The client constructs the inner message for the intended backend, creates an innocuous outer message for a client-facing server, and encrypts the inner message into extension 0xfe0d. The client-facing server decrypts and forwards the inner handshake to the correct backend.
ECH protects more than SNI: sensitive extensions such as ALPN can be carried in the inner message. It does not make a connection invisible. Source and destination IP addresses, ports, timing, byte counts, transport behavior, the public-facing service, and sometimes DNS remain observable. The privacy goal is that backend names inside the same anonymity set are difficult for an on-path observer to distinguish.
DNS may explain the destination—or disappear from the sensor
Clients need an ECH configuration before offering real ECH. RFC 9848 specifies publication through the DNS bindings defined by SVCB and HTTPS records. An HTTPS record can carry the configuration, while resolver behavior, caching, client policy, and encrypted DNS determine whether an enterprise resolver ever observes the lookup.
Plaintext enterprise DNS can still associate a device with the requested name, but time alignment must account for cache hits, prefetching, shared resolvers, aliases, and applications that resolve through their own encrypted channel. A destination IP may host hundreds of names. Conversely, a dedicated IP can still disclose the likely service even when SNI is hidden.
The right DNS investigation records the complete resolution path: client, resolver, encrypted resolver policy, query and response type, aliases, TTL, cache state, answer set, and connection time. Do not join the nearest query to a flow and call it proof. State whether the relationship is direct, inferred through timing, or unavailable.
Record what the sensor knows, not the hostname it guesses
A network record should separate observation from enrichment. The following authored JSON is illustrative, not a claim about one vendor’s exact schema:
{
"ts": "2026-11-10T11:08:41.382Z",
"src_ip": "10.24.8.19",
"dst_ip": "192.0.2.44",
"dst_port": 443,
"transport": "tcp",
"tls_version": "1.3",
"client_hello_extension": "0xfe0d",
"ech_observation": "offered_or_greased",
"outer_server_name": "public.example-edge.net",
"inner_server_name": null,
"bytes_out": 18432,
"bytes_in": 97218
}
The extension alone does not prove ECH was accepted. RFC 9849 defines GREASE ECH so capable clients can send a dummy extension when no usable configuration exists, preventing real ECH from becoming a unique fingerprint. An on-path sensor generally cannot decrypt the inner name or always distinguish genuine use from GREASE.
Enrich with stable facts: endpoint identity and process, destination ownership, approved proxy path, certificate or TLS details visible at the observation point, DNS evidence, connection history, volume, and resource-side logs. Avoid inventing an SNI from an IP-to-domain database without labeling it as an inference.
Move controls to places that retain trustworthy context
Managed endpoints can associate a socket with a process, signer, user, browser profile, and policy. Enterprise resolvers can enforce domain policy when clients are required to use them. Explicit secure web gateways can apply policy when the client intentionally establishes a managed tunnel or the organization performs authorized TLS inspection. Cloud services can log authenticated resource access after the connection arrives.
Combine these with NetFlow monitoring for new destination infrastructure, rare autonomous systems, unusual volume, beacon timing, and deviations from peer behavior. These features are not replacements for destination identity; they are different signals with different false-positive modes.
Detection assurance should include accepted ECH, GREASE ECH, rejected ECH with retry, cached DNS, encrypted DNS, QUIC, shared CDN destinations, and proxy failure. A test browser visiting an approved ECH site is authored simulation behavior, not live malicious activity. Document exactly which visibility was expected at each sensor.
Do not trade privacy away without proving the control need
A blanket ECH block may restore a field to one sensor while pushing users toward unmanaged networks, breaking modern clients, or weakening privacy against local observers. Before enforcement, identify the decisions that genuinely depend on plaintext SNI and whether endpoint, resolver, or proxy controls can make them with better identity context.
Stage any policy: measure ECH and GREASE prevalence, map application owners, pilot managed clients, monitor failures, publish exception criteria, and define rollback. Distinguish inability to inspect content from inability to control access. Many organizations can govern browsers, resolvers, applications, identities, and destination services without decrypting every handshake.
Keep the claim bounded: ECH removes specific TLS handshake visibility from specific observation points. It does not eliminate network telemetry, endpoint evidence, DNS in every deployment, or server-side audit.
Build the post-SNI evidence map before visibility changes
Next step: extend your encrypted traffic metadata inventory with an ECH column for every sensor and decision. Record whether it observes the outer name, real ECH versus GREASE, client identity, process, resolver path, proxy policy, destination ownership, and service-side action. Then test one approved ECH connection end to end.
The useful outcome is not “ECH is good” or “ECH is bad.” It is a defensible monitoring design that preserves user privacy while maintaining the identities and consequences needed for security decisions.
Frequently asked questions
Does Encrypted Client Hello hide the destination IP address?
No. ECH encrypts the inner ClientHello, including the real SNI, but the observer can still see network-layer destinations and the public-facing service. Shared hosting and encrypted DNS can make that evidence less specific.
Should an organization block ECH to preserve inspection?
Not as a default reaction. Blocking can reduce user privacy and break applications. First determine which controls truly depend on plaintext SNI, then move enforcement to managed endpoints, explicit proxies, resolvers, and destination-aware service telemetry.
