RFC 9849 standardizes Encrypted Client Hello (ECH), finally encrypting the last significant plaintext metadata in TLS 1.3 handshakes. While this protects user privacy from network surveillance, it systematically dismantles the observability infrastructure that Site Reliability Engineers depend on: SNI-based load balancing, hostname-aware WAF rules, and straightforward packet inspection for debugging. This analysis explores the architectural trade-offs between perfect forward secrecy and operational visibility, examining how split-mode ECH deployments create new complexity for cloud-native architectures and why your current monitoring stack might be flying blind.
When Perfect Encryption Meets Imperfect Infrastructure
The IETF published RFC 9849 in March 2026, moving ECH from experimental draft to Standards Track. For privacy advocates, this is a victory decades in the making: the Server Name Indication (SNI) extension, which previously leaked the target domain in plaintext, is now encrypted under the server’s public key using Hybrid Public Key Encryption (HPKE). No more ISPs selling browsing histories based on unencrypted handshakes. No more authoritarian regimes blocking specific domains by inspecting TLS Client Hello packets.
For infrastructure engineers, however, RFC 9849 reads like a manual for breaking production.
The problem isn’t that ECH is poorly designed, it’s actually elegant. The protocol splits the Client Hello into two messages: a ClientHelloOuter containing only a public name (like cloudflare.com or fastly.com), and an encrypted ClientHelloInner containing the actual destination (like customer-blog.example.com). Only the client-facing server can decrypt the inner message to reveal the true destination, then forward it to the backend server in what the RFC calls “split mode” topology.
This creates a fundamental architectural tension: the same mechanism that prevents passive surveillance also prevents active legitimate inspection by load balancers, WAFs, and monitoring tools that sit between the client and the TLS terminator.
Your Load Balancer Just Lost Its Glasses
Modern cloud architectures rely heavily on SNI-based routing. When a packet hits an edge load balancer, the balancer inspects the plaintext SNI extension to determine which upstream service should handle the connection. With ECH enabled, that inspection returns only the public name of the ECH service provider, not the actual origin server.
As noted in Section 8.2 of the RFC, “server deployments which depend on SNI, e.g., for load balancing, may no longer function properly without updates.” The nature of those updates is “out of scope of this specification”, which is RFC-speak for “good luck figuring it out.”
In split mode deployments, the client-facing server must decrypt the ECH extension, extract the ClientHelloInner, and forward it to the appropriate backend. This means your load balancer is now either:
1. The client-facing server itself (requiring private key access and trial decryption), or
2. Completely blind to the traffic it’s supposed to be distributing
The trial decryption process isn’t free. Section 10.4 warns that when clients randomize their config_id to prevent tracking (a privacy feature), servers must perform trial decryption against all known keys. This opens a lovely new DoS vector: attackers can send malformed Client Hellos that force expensive decryption operations. The RFC recommends rate limiting, which is another way of saying “your observability now costs CPU cycles and complexity.”
WAFs and the End of Hostname-Based Filtering
Web Application Firewalls have historically relied on the SNI to apply domain-specific rule sets. When bank.example and blog.example share an IP behind a reverse proxy, the WAF uses the SNI to determine whether to apply strict financial compliance rules or permissive content filtering.
With ECH, the WAF sees only the public name of the ECH provider. The actual destination is encrypted until it reaches the client-facing server. This creates where monitoring shows green but architectural failures exist: your WAF dashboard shows traffic flowing normally, but it’s applying generic rules to specific domains, potentially missing targeted attacks because it doesn’t know which domain is actually being accessed.
The RFC acknowledges this in Section 8.2, noting that “use cases which depend on information ECH encrypts may break with the deployment of ECH.” The document suggests that in managed enterprise settings, one approach may be to disable ECH entirely via group policy, a solution that preserves security tools at the cost of user privacy, essentially defeating the purpose of the standard.
GREASE: When Fake Traffic Looks Real
To prevent fingerprinting of ECH-capable clients, the RFC mandates GREASE (Generate Random Extensions And Sustain Extensibility). Clients without ECH configurations send fake ECH extensions filled with random data that servers must ignore.
From a monitoring perspective, this is maddening. Your observability tools can’t distinguish between legitimate ECH traffic and GREASE padding without attempting decryption. Section 6.2 specifies that GREASE ECH uses random config_id values and plausible cipher suites, meaning your metrics will show ECH “adoption” that may simply be clients sending decoy packets.
AdGuard’s recent CLI v1.3 release demonstrates the client-side momentum: they’ve added DNS filtering and ECH support to their command-line tools, enabling users to encrypt their Client Hellos by default. As client adoption accelerates, the percentage of blind traffic hitting your infrastructure will only grow.
The Split Mode Architecture Tax
The RFC defines two topologies: “shared mode” (where one server handles everything) and “split mode” (where a client-facing server decrypts and forwards to a backend). Split mode is where most operational pain lives.
In split mode, the client-facing server must maintain an authenticated channel to backend servers, as noted in Section 10.1. The RFC explicitly states that “the exact mechanism for establishing this authenticated channel is out of scope for this document.”
This is where when configuration decisions lead to production outages becomes particularly relevant. The ECH configuration, distributed via DNS SVCB or HTTPS records, controls which public keys clients use to encrypt their hellos. If your DNS records cache stale configurations while your server rotates keys, clients will encrypt to keys you no longer possess, triggering the retry mechanism described in Section 6.1.6.
The retry mechanism sounds robust: if decryption fails, the server sends retry_configs with updated keys. In practice, this means failed connections, latency spikes, and support tickets. The RFC warns that clients should not accept retry configurations in response to a retry, as this indicates a “misconfigured” server, diplomatic language for “your infrastructure is broken.”
What SREs Can Actually Do
The RFC isn’t entirely unsympathetic to operational concerns. Section 8.2 suggests that server operators may need to intercept and decrypt client TLS connections as an alternative solution, a controversial recommendation that essentially describes a man-in-the-middle attack, though one performed by the legitimate infrastructure owner.
More practical approaches include:
-
Moving termination to the edge: Accept that the client-facing server must decrypt and re-encrypt, maintaining visibility at the cost of end-to-end encryption between client and origin. This violates the “multi-party security contexts” goal of Section 10.10.6, but preserves observability.
-
Using the public name as a routing hint: While the
ClientHelloOuteronly contains the public name (e.g.,cdn.example.com), you can still route to specific clusters based on that name, then handle the decryptedClientHelloInnerat the cluster level. This adds hop latency but maintains some distribution capability. -
Embracing encrypted observability: Shift from packet inspection to application-layer telemetry. If you can’t see the SNI in the handshake, instrument the backend servers to report which domains they’re serving via sidecar proxies or eBPF programs that hook into the decrypted traffic.
The harsh reality is that ECH forces a re-architecture of how we handle TLS traffic. The days of passive, non-intrusive network monitoring are ending. As one infrastructure blogger noted when ECH achieved Standards Track status, this represents “基礎建設” (infrastructure) changes that reduce detectability, precisely the point, but precisely the problem for operators.
The Inevitable Trade-off
ECH doesn’t just encrypt data, it encrypts intent. The ClientHelloInner contains not just the SNI, but the ALPN list, supported cipher suites, and other parameters that previously allowed middleboxes to optimize or secure traffic. Section 10.5 explicitly warns that clients should not send sensitive values in the ClientHelloOuter, meaning load balancers can’t even use ALPN hints for protocol routing.
For privacy, this is correct. For reliability engineering, it’s a regression to the dark ages. We’re moving from an internet where “the network is the computer” to one where “the edge is a black box.”
The RFC 9849 authors know this. The document is peppered with warnings about “deployment impact” and “compatibility issues.” But the standard is now official, and client implementations are shipping. Firefox 119+ and Chromium 117+ already enable ECH by default when DNS-over-HTTPS is active.
The question isn’t whether to adopt ECH, it’s whether your observability stack can survive the transition. Because once those Client Hellos go dark, there’s no magic decryption key for your load balancer. The only visibility you’ll have is what the application itself chooses to tell you. And if history is any guide, applications are terrible at self-reporting.
Welcome to the encrypted internet. Hope you brought your own telemetry.
