The website has just shut down one of its most well-known privacy leaks. Encrypted Client Hello, widely known as ECH, is now an official standard from the IETF, the organization responsible for defining many of the core Internet protocols. The specification was published on March 3rd as RFC 9849, giving formal recognition to a technology that is set to change how encrypted web traffic is protected and further complicate domain name-based blocking during connection establishment.
This news has significant technical implications, but also political, legal, and business ones. For years, the TLS protocol has encrypted the content of HTTPS connections, but it left a particularly sensitive piece of data visible: the SNI, the field where the browser indicates which domain it wants to connect to when multiple websites share an IP. This information has been a key element for operators, filtering systems, and selective blocking mechanisms. With ECH, this data no longer travels in plain text.
The change doesn’t encrypt “more web,” it encrypts the connection start better
What ECH does is not replace HTTPS, but strengthen it at one of its most delicate points. Although TLS 1.3 had already greatly improved handshake privacy, it still exposed the SNI and some initial metadata. RFC 9849 defines a mechanism to encrypt the browser’s ClientHello using the server’s public key, so network observers can no longer clearly see the actual domain being accessed.
This does not mean that ECH renders all browsing invisible. The standard itself makes clear that it alone isn’t enough to hide the server’s identity if DNS queries are still visible in plaintext or if the destination’s IP address is unique and easily identifiable. But it does eliminate one of the most useful signals for passive traffic inspection. In an Internet where many websites share IPs and encrypted DNS is gradually advancing, the practical effect can be very significant.
Additionally, ECH did not emerge from nothing or a single company. The standard is the result of years of work at the IETF and is signed by Eric Rescorla, Kazuho Oku, Nick Sullivan, and Christopher A. Wood, involving experts linked to actors such as Apple, Fastly, and the technical ecosystem that has driven this evolution around TLS. In parallel, a complementary document, RFC 9848, specifies how to advertise these ECH configurations via DNS SVCB and HTTPS records, an essential piece for its real deployment.
Cloudflare, Firefox, and major browsers accelerated the jump
Although the official standard is now finalized, practical implementation has been underway for some time. In 2023, Cloudflare announced the availability of ECH across all its plans, and in 2024, it explained they continued to enhance its implementation alongside browser ecosystem partners. Mozilla, for its part, introduced ECH in Firefox 118 and enabled it by default starting with Firefox 119, presenting it as a direct privacy enhancement against network intermediaries.
Apple has also been moving in that direction. Its developer documentation now supports enabling Encrypted Client Hello within the security framework, a clear sign that the technology is already part of the technical landscape for major platforms. In other words, the formalization of the RFC doesn’t start from scratch: it arrives when the technical groundwork is already laid and several key players have been preparing the terrain for some time.
This is important because, on the Internet, becoming a standard does not always mean immediate adoption. But in this case, ECH benefits from an unusual advantage: deployment experience already exists, browsers are already using it, and infrastructure operators are already serving it. So everything indicates that its expansion will be gradual but steady.
Why ECH conflicts with domain-based blocking models
The approval of ECH is not only relevant for network engineers and privacy experts. It also directly impacts those who rely on SNI for implementing restrictions. In Spain, this clash has been especially visible in the fight against audiovisual piracy. LaLiga and Telefónica have defended court-ordered blocking measures initially based on domains and IPs, then migrating to more aggressive mechanisms once encryption reduced the effectiveness of traditional filtering.
Specialized media with access to parts of judicial documentation claim that LaLiga and Telefónica explicitly mention ECH and Apple’s Private Relay as technologies that diminish the effectiveness of traffic analysis-based blocks. In this context, the response shifted from blocking specific domains to widening focus to entire IP addresses, with the risk of affecting third parties sharing infrastructure.
LaLiga, on the other hand, holds a very different view. In its official March 2025 statement, it claimed the courts backed its strategy and denied that indiscriminate blocking or reduced guarantees occurred. The debate is not closed: one side sees it as a legitimate measure defending audiovisual rights, and the other as a technically disproportionate practice that harms innocent services and users.
What ECH fundamentally changes is the technical landscape. If the real domain name is no longer available in plaintext during TLS handshake, traffic filtering based on this information becomes much less effective. This pushes toward more invasive solutions, such as IP blocking, or toward more complex and costly approaches. That’s one of the reasons why this RFC is so significant beyond purely technical circles.
A standard designed for privacy but with broader effects
ECH’s primary goal is to enhance privacy and reduce exposure of sensitive metadata. However, like many security technologies, its impact extends beyond its original use case. It also complicates passive censorship, limits certain forms of network surveillance, and forces rethinking of legacy tools for management, filtering, or control.
This doesn’t mean all problems vanish. The standard itself dedicates sections warning about deployment errors, middleboxes, incompatibilities, and practical limits. It also makes clear that some uses relying on plaintext TLS info will need alternatives—whether in corporate environments, proxies, or more intrusive inspection systems. But the overall message is clear: the old plaintext SNI no longer fits as a core component of the future Web.
Moving forward, the question isn’t whether ECH should become a standard, but how quickly browsers, CDNs, hosting providers, and operators will adopt it. Meanwhile, those who built parts of their blocking or monitoring capacity around a metadata leak that the Web itself is now closing will have to adapt.
Frequently Asked Questions
What is ECH and what is it for?
ECH, or Encrypted Client Hello, is a TLS extension that encrypts the initial connection message from the browser to the server. Its main function is to hide the actual destination domain and other sensitive metadata that previously could be seen during the start of an HTTPS connection.
Does ECH replace HTTPS or TLS 1.3?
No. ECH does not replace HTTPS or TLS 1.3 but complements them. It enhances the initial connection phase by encrypting elements like the SNI that were previously visible.
Why does ECH make it harder for operators to block websites?
Because many selective blocks relied on reading plaintext SNI to identify which domain the user wanted to visit. If that data is encrypted, the technique loses effectiveness, requiring the use of broader or more intrusive methods.
Does ECH hide all the websites a user visits?
Not always. The standard acknowledges that other clues, such as unencrypted DNS queries or easily associated IP addresses, may still reveal information. So while ECH improves privacy significantly, it doesn’t guarantee complete anonymity in all scenarios.
Sources: