One of the web’s longest-standing privacy leaks has just been addressed at the standards level. The IETF has published RFC 9849, which formally defines TLS Encrypted Client Hello (ECH) as a Standards Track / Proposed Standard. The document, updated on March 3, 2026, describes a mechanism for encrypting the ClientHello message in TLS using a server public key, closing one of the most visible gaps left in the early stages of a secure web connection.
The importance of this move is not that it creates a “new HTTPS,” but that it protects a part of the connection setup that remained exposed even in the TLS 1.3 era. As RFC 9849 explains, although TLS 1.3 already encrypts most of the handshake, including the server certificate, the Server Name Indication (SNI) field in the ClientHello was still sent in plaintext. That field reveals the target domain a user is trying to reach, making it one of the most sensitive pieces of metadata still visible to on-path observers. The RFC states that ECH is designed to protect that SNI information, along with other potentially sensitive fields such as ALPN.
ECH does more than hide a single field. The standard defines a split between a ClientHelloInner, which contains the real sensitive information, and a ClientHelloOuter, which acts as the public wrapper. The outer message carries an encrypted_client_hello extension containing the encrypted inner message. If the server can decrypt it, the connection proceeds with the protected inner data; if not, the protocol defines a retry and recovery mechanism. In practice, this means the initial TLS negotiation can now be structured so that the truly sensitive part of the handshake is concealed from the network from the outset.
The RFC also makes clear that ECH is built for the way the modern web actually works. It supports two deployment models: shared mode, where the same provider acts as both the client-facing and backend server, and split mode, where a front-end service handles the client connection and relays it to a backend that terminates TLS. That matters for CDNs, reverse proxies, and large hosting platforms where many domains sit behind shared infrastructure. The standard’s goal is to make connections to servers within the same “anonymity set” harder to distinguish from one another.
What RFC 9849 changes in practice
From a deployment perspective, RFC 9849 turns ECH from a widely discussed feature into an official part of the Internet standards stack. The Datatracker entry shows it as the final form of the former draft-ietf-tls-esni, with authors Eric Rescorla, Kazuho Oku, Nick Sullivan, and Christopher A. Wood. The RFC itself says it is an Internet Standards Track document, that it represents IETF community consensus, and that it was approved for publication by the IESG.
That matters because standards are not just technical papers; they are the documents vendors, browser makers, CDN operators, and enterprise networking teams use as the common reference for interoperable deployment. RFC 9849 also ties into the broader DNS-based bootstrap model around ECH. The text notes that domains can publish ECH configurations and that publication details are delegated elsewhere, while the RFC itself focuses on the TLS mechanism and wire format. In other words, the standard is not a theoretical privacy upgrade — it is a blueprint intended for real-world deployment across browsers, front-end infrastructure, and origin systems.
The document also goes beyond simple message format definitions. Its table of contents shows extensive sections on client behavior, server behavior, deployment considerations, compatibility issues, security considerations, attack mitigation, and IANA registry updates. That breadth is a sign of maturity: ECH is no longer being treated as an experimental idea but as an operational protocol that must work across middleboxes, retries, split infrastructures, and misconfigurations.
Better privacy, but not total invisibility
One of the strengths of RFC 9849 is that it avoids overselling what ECH can do. The introduction explicitly states that ECH is not, by itself, sufficient to protect server identity in every case. The target domain may still be exposed through plaintext DNS queries or through visible server IP addresses. The document points to encrypted DNS mechanisms such as DNS over HTTPS, DNS over TLS/DTLS, and DNS over QUIC as part of the broader privacy picture.
That limitation is important. ECH significantly improves handshake privacy, but it does not make browsing totally opaque on its own. Its real power appears when it is combined with encrypted DNS and with hosting environments where multiple domains share infrastructure. In those settings, hiding the SNI removes one of the clearest signals available to passive observers trying to identify the exact destination of a connection.
The RFC is equally candid about cryptographic trade-offs. In its security considerations, it says the design does not provide forward secrecy for the inner ClientHello, because the ECH key is static. However, it also notes that the exposure window is limited by key lifetime and recommends regular key rotation. That is a practical engineering compromise rather than a hidden flaw: the protocol improves privacy substantially while acknowledging where its protection boundaries still lie.
A standard with wider consequences
RFC 9849 is also notable because it openly acknowledges deployment friction. In its deployment impact section, the document states that some use cases that depend on plaintext TLS information may stop working as expected. It specifically notes that in managed enterprise environments one possible response may be to disable ECH through group policy, and that server deployments relying on visible SNI — for example for routing or other functions — may need updates. That is a polite but clear admission that stronger privacy often breaks long-standing assumptions in network operations.
That is why this RFC matters beyond pure protocol design. It formalizes a shift in the architecture of the web: plaintext SNI is no longer being treated as an acceptable long-term feature of secure browsing. Instead, the standards process is moving the web toward a model in which fewer metadata clues are exposed at the start of a connection. For users, that means stronger privacy over time. For infrastructure providers, it means implementation work. And for systems that relied on reading early TLS metadata, it marks the beginning of the end of that visibility as a default convenience.
Frequently asked questions
What is RFC 9849?
RFC 9849 is the IETF document that defines TLS Encrypted Client Hello (ECH) as a Standards Track / Proposed Standard, published in March 2026. It describes how to encrypt the ClientHello message in TLS under a server public key.
What does ECH protect?
ECH protects the SNI field and other potentially sensitive parts of the initial TLS handshake, including fields such as ALPN, which were previously visible to observers on the network.
Does ECH completely hide what website a user is visiting?
No. RFC 9849 explicitly says that the target domain can still be exposed through other channels, such as unencrypted DNS queries or visible server IP addresses. ECH improves privacy significantly, but it is not a complete anonymity system on its own.
Why is RFC 9849 important for the future of the web?
Because it turns ECH into an official Internet standard and gives browsers, CDNs, and infrastructure providers a stable specification for deployment. It also signals a broader shift away from exposing sensitive TLS metadata by default.