# TLS Encrypted Client Hello Becomes a Standard (RFC 9849)
Table of Contents
For years, anyone watching network traffic could read one detail that many people assumed was already protected: the name of the site you were connecting to. The connection was encrypted, the padlock in the browser was closed, and yet that piece of information traveled in the clear. In March 2026 the IETF, the body that writes Internet standards, published RFC 9849, titled “TLS Encrypted Client Hello.” The document closes exactly that gap. It’s worth understanding what it really hides, and why it matters to anyone who designs reverse proxies, CDNs, and filtering systems.
The detail that stayed exposed
When a browser opens a secure connection to a site, the two sides first exchange a few messages to agree on keys and parameters. This phase is called the handshake. With the most recent version of the protocol, TLS 1.3, almost the entire handshake is encrypted: an outside observer just sees unreadable bytes go by.
There was one important exception, though. In the very first message, the ClientHello, the browser has to say which site it wants to reach. That’s necessary because a single IP address can host hundreds of different sites, and the server needs to know which certificate to present. This indication is called SNI, short for Server Name Indication, and until now it traveled in the clear. In practice, anyone along the path of the connection (a network operator, an ISP, a corporate firewall) could read example.com without seeing any of the actual content. As the RFC itself puts it, the plaintext SNI is perhaps the most sensitive piece of information left exposed in TLS 1.3.
What Encrypted Client Hello is
Encrypted Client Hello, shortened to ECH, is a TLS 1.3 extension that encrypts the ClientHello, and with it the SNI. Not just the site name: it also protects other fields that could hint at the destination, such as the list of application protocols the client is willing to use (the ALPN extension).
The idea isn’t new. It grew out of years of work on an earlier proposal called ESNI, which encrypted only the site name. Over time it became clear that hiding a single field wasn’t enough: other details in the ClientHello could give away the destination. The proposal was therefore redesigned to encrypt the whole message, and that’s the version that reached standard status with RFC 9849. The document has Proposed Standard status, the first rung on the official IETF standards track: it’s stable and published, no longer a draft.
How it works, without the jargon
The mechanism is built around two nested ClientHellos. There’s an “inner” one, the real one, which carries the true SNI and gets encrypted. And there’s an “outer” one, visible, which carries a public, innocuous name shared by many sites hosted behind the same operator.
Anyone watching from outside sees only the public name. The server that receives the connection, called the client-facing server, decrypts the inner ClientHello, figures out which site was actually requested, and routes the connection accordingly. If many sites share the same public name, they become indistinguishable to an observer: that’s what the spec calls an anonymity set.
To encrypt the inner ClientHello, the client needs the server’s public key. It obtains that key through DNS, the system that translates names into addresses. A companion document published alongside the first one, RFC 9848, defines how to publish this configuration (the ECHConfig) in DNS records of type SVCB and HTTPS, using a dedicated parameter called ech. The encryption itself uses HPKE, a standard cryptographic scheme designed precisely for encrypting data toward a public key.
The design also covers the cases where something doesn’t line up. If the server can’t decrypt, for example because the client used a configuration that has since expired, it can respond with an updated one and the connection is retried. And there’s a trick called GREASE: clients can send fake ECH data even when they aren’t really using it, so that ECH users don’t stand out from the rest and network equipment doesn’t “get used to” expecting a fixed format.
What changes for reverse proxies, CDNs, and filters
This is the practical part, the one that affects people who run infrastructure.
Many reverse proxies route connections by reading the SNI without even decrypting the traffic: they look at the name, pick the right backend, and pass it along. With ECH this no longer works, because the visible SNI is the shared public name. To route based on the real site, the exposed server has to become the client-facing server in full: decrypt the ECH and read the inner SNI. Anyone who built their routing on plaintext SNI alone will need to rethink the architecture.
For CDNs the model fits well. A CDN already hosts many customers behind the same addresses: it can present a common public name, act as the client-facing server, and route to the correct site after decrypting the ECH. It’s also the setting where the anonymity set is largest, and therefore where the protection is most effective.
SNI-based filters are a different story. Firewalls, parental controls, corporate filters, and network-level blocking tools often decide what to let through by reading the site name in the SNI. With ECH that name is no longer visible: a filter that relies only on the SNI loses its foothold. It’s the flip side of the privacy gain, and it’s worth knowing about early, without assuming that nothing will change.
Where we stand
ECH is a published standard, but its effect depends on how widely both sides adopt it. On the client side, some browsers have already been experimenting with ECH for a while. On the server side, several CDNs offer it and cryptographic libraries are adding support: a few days after publication, the OpenSSL project announced support for ECH as described in RFC 9849.
A few prerequisites are worth keeping in mind. ECH requires TLS 1.3, so connections that fall back to older versions stay exposed. And it depends on DNS to fetch the configuration: if DNS queries travel in the clear, an observer can still infer the destination or tamper with the configuration. That’s why ECH mostly makes sense together with encrypted DNS, such as DNS over HTTPS or DNS over TLS.
In short, RFC 9849 shields the last piece of the handshake that was still readable. It isn’t a sudden revolution: it’s a building block that becomes official after years of field testing, and one that over the coming months will quietly change how reverse proxies, CDNs, and network filters see, or no longer see, the names of the sites people visit.
