- ECH encrypts the ClientHello TLS message, hiding the domain (SNI) you are visiting and significantly improving your privacy from carriers and other intermediaries.
- Its deployment relies on encrypted DNS (DoH/DoT), new HTTPS records, and CDNs like Cloudflare, which complicates selective website blocking based on SNI analysis.
- The main browsers already support ECH and, combined with DoH and VPNIt offers a very powerful layer of protection on home, public and corporate networks.
- Although compatibility issues and incomplete adoption remain, ECH is emerging as the key step to closing the remaining metadata leaks in TLS 1.3.

ECH (Encrypted Client Hello) has become one of the star themes When we talk about privacy, website blocking, and fights between operators, major platforms like Cloudflare, and organizations like LaLiga, it's not a passing fad: it's the missing piece in HTTPS encryption that needed to close a loophole through which a lot of information about our online activity was leaking.
In short, ECH is used to hide the exact domain of the website you are connecting to. even if you're already using HTTPS. Until now, carriers, censorship systems, or deep packet inspection equipment (DPIThey could tell which domain you were entering thanks to a field called SNI in the TLS protocol. With ECH, that data is encrypted, which greatly complicates selective blocking and significantly improves user privacy.
What is ECH and what problem does it solve?
ECH (Encrypted Client Hello) is an extension of the TLS protocolThis is the same protocol used in HTTPS connections for virtually all modern websites. Its main purpose is to encrypt the initial message that the browser sends to the server, called ClientHello, which contains highly sensitive privacy parameters.
The critical point in all of this is the SNI (Server Name Indication) field.When you access a secure website, your browser and the server perform a TLS handshake to agree on encryption keys and algorithms. Before ECH, although the subsequent content of the connection was encrypted, the domain name you wanted to access was sent in plain text within that SNI (Single Name Interface). This meant that anyone located between your computer and the server (ISP, corporate firewall, government censor, attacker on a public Wi-Fi network, etc.) could see which domain you were accessing.
This has been exploited for years to implement selective website blocking.The operators set up Deep Packet Inspection (DPI) equipment that analyzes TLS traffic, reads the SNI, and if they detect a "forbidden" domain, they cut off the connection and send you a blocking message. Even if everything else is encrypted, that plaintext data was enough to filter and censor.
With ECH, the ClientHello is encrypted using a public key obtained via DNSTherefore, the SNI and other parameters are no longer visible. From the outside, all that is observed is that you are connecting to a specific IP address (which in the case of Cloudflare can host thousands of different websites), but it is not known exactly which domain you are requesting.
The beauty of it is that ECH doesn't redesign the Internet from scratch.It is integrated as an extension of TLS 1.3, also relying on technologies such as DNS over HTTPS (DoH), DNS over TLS (DoT) and new types of DNS records (such as HTTPS) to distribute the necessary public keys without exposing them to attacks or manipulation.

How the SNI worked and why it was a privacy sieve
To understand what ECH is for, first we need to see the hole it plugs: SNIThese days, it's very common for a single IP address to host dozens, hundreds, or even thousands of different websites, especially behind CDNs like Cloudflare. The server needs to know exactly which site you want to go to in order to show you the correct TLS certificate and establish a secure connection to the right website.
That's where the SNI field comes into play.In the ClientHello message, the browser indicates: “I want to talk to this specific domain.” Servers use this information to select the certificate and configure the connection, but the problem is that travels in plain text before any encryption existsResult: all intermediate nodes can read it easily.
With that simple piece of information, many far from innocent things can be done.: since block websites using firewall rulesThis includes censoring news websites, political party pages, or competing services. There's no need to break the encryption or read the content; simply knowing which domain to access and blocking the channel at that point is enough.
With that simple piece of information, many far from innocent things can be done.Operators set up Deep Packet Inspection (DPI) equipment that analyzes TLS traffic, reads the SNI and, if they detect a "forbidden" domain, cuts off the connection and sends you a blocking message.
This situation clashed head-on with the general evolution of TLS towards full encryption of the handshake protocol.With TLS 1.3, a significant leap had already been made: many more handshake messages were encrypted than in TLS 1.2, improving both security and speed. But one "final window" remained open: the SNI and other ClientHello parameters were still exposed to anyone.
What exactly does ECH do and how does it encrypt ClientHello?
ECH takes a new approach to how TLS is negotiatedInstead of sending a single plaintext ClientHello, the browser constructs two versions: a ClientHelloOuter and a ClientHelloInner. The Outer version is unencrypted, as usual, but the Inner version, which contains the sensitive data (actual SNI, ALPN list, parameters that reveal which application or service you will use, etc.), is encrypted using a public key that the server has previously published in DNS.
The general flow would be something like this:
- The client obtains, via DNS (and preferably via DoH or DoT), an ECH public key associated with the domain you want to access. That key is stored in special records (like HTTPS) that describe the server's TLS capabilities.
- The browser constructs the ClientHelloInner with the actual destination information (the specific domain behind the CDN, the ALPN list, etc.) and encrypts it with that public key using HPKE (Hybrid Public Key Encryption).
- That encrypted ClientHelloInner is included as an extension within the ClientHelloOuter.The Outer layer is what any device on the network sees. It contains minimal parameters to prevent the connection from breaking, but without filtering sensitive data.
- When the server receives the request, it attempts to decrypt the ECH blockIf it can decrypt it, it uses the ClientHelloInner and continues the handshake with the actual destination website. If it cannot (for example, because the client has an outdated public key), it completes the handshake with the ClientHelloOuter and sends the client the correct ECH key so they can try again.
This design solves several problems at once.On one hand, it protects the SNI and other private parameters within the ClientHelloInner. On the other hand, it better handles cases where keys change or the DNS has cached versions, preventing the connection from failing outright, as happened with the previous attempt called ESNI (Encrypted SNI).
ESNI was the direct precursor of ECHIn ESNI, only the SNI extension was encrypted, using a public key distributed via DNS. If the server couldn't decrypt it (due to an expired key or DNS inconsistency), the connection was aborted. Cloudflare did implement ESNI and rotated the key every hour, but its performance in real-world scenarios revealed several issues, especially with slow or inconsistent DNS caches.
ECH expands the approach and encrypts the entire ClientHello (at least the sensitive part)not only the SNI. Furthermore, its design explicitly considers this "escape route" using ClientHelloOuter to avoid bringing down the connection when there are key problems, and relying on new DNS specifications and HPKE to simplify the cryptographic part.

Relationship between ECH, encrypted DNS, VPN, and other privacy technologies
ECH does not exist in isolation: it relies on other pieces of the current Internet architectureFor it to work securely, the distribution of the ECH public key via DNS must not be spied on or manipulated by anyone on the network.
This is where DNS over HTTPS (DoH) and DNS over TLS (DoT) come into play.Both protocols encrypt DNS queries, so the domains you resolve aren't sent in plain text. If you activate ECH but continue using traditional, unencrypted DNS, your ISP or any intermediary would still see the DNS requests, so much of the benefit is lost.
Modern browsers have already taken important steps:
- Firefox It integrates DoH and, in fact, only allows the use of ECH if DoH is active. In its advanced configuration (about:config), several "echconfig" options can be seen set to true, indicating that the extension is enabled, and the fallback is disabled to prevent easily reverting to plaintext SNI.
- Chrome, Edge, and other Chromium-based browsers They allow you to enable secure DNS in their privacy and security menus. The user can choose providers such as Cloudflare, Google or others incorporated.
ECH also works well with VPNsA VPN encrypts all traffic and hides your public IP address behind the provider's, but even with a VPN, without ECH, your SNI could still be visible to the VPN provider or other elements of its network. With ECH enabled over a VPN, additional layers are added: your IP address is masked by the VPN, and the domain you're accessing is also protected within the encrypted ClientHello message.
In public networks such as cafes, airports or hotels, ECH makes even more senseIn these environments, the risk of traffic interception or manipulation is higher. By combining ECH, DoH/DoT, and, if you want to take it a step further, a VPN, you minimize the information that third parties can infer about your connections: not the exact domain, not the content, not even your real source IP address.
The conflict between ECH, LaLiga, Cloudflare and the operators
The theory is all well and good, but ECH has also uncovered a head-on clash of interests between those who want to strengthen the general privacy of the network and those who use the SNI as a tool to block content, as is the case in the fight against illegal football broadcasts.
Things started to heat up when Cloudflare massively activated ECH on its networkIn October 2023, the CDN decided to deploy ECH for millions of domains, which in practice meant that operators could no longer see which specific domain was being requested behind a shared IP address. If an IP address hosts both legitimate websites and IPTV services of dubious origin, when ECH is enabled, the operator can no longer block only the "pirate" website by reading the SNI (Service Network Identification Number).
In that scenario, only two inelegant options remain.Either the entire IP address is blocked (taking down hundreds or thousands of perfectly legitimate websites in the process), or nothing is blocked and those services escape filtering. This dilemma has caused outages and access problems for many Spanish companies hosted on Cloudflare when certain operators have opted for the mass blocking of IPs.
The conflict has been particularly acute regarding the blockades implemented by LaLiga. To curb illegal IPTV lists, cases have been documented where, when attempting to access websites hosted by Cloudflare from certain operator networks, users encountered messages stating "Content blocked at the request of the Competent Authority." In some cases, simply having ECH and DoH enabled in the browser was enough for the same domain to load without problems, demonstrating that the filtering systems were no longer able to detect the SNI (System Network Identification).
Operators such as Movistar, O2, Orange, DIGI or Vodafone have reacted differentlySome have softened the blocks in the face of collateral impact and bad image; others have tightened them, and some claim to have more refined systems based on traffic pattern analysis or advanced DPI, although without giving too many public details.
Amidst all this, Cloudflare has been fine-tuning its ECH deploymentInitially, it was offered as an option for certain sites, then enabled by default across the entire network, and, due to compatibility issues and a high rate of browsing errors, was disabled globally again. Later, in 2024, it was gradually re-enabled, coinciding with improved browser support and infrastructure adjustments.
The result is a direct clash between privacy and SNI-based blocking modelsECH makes it "technically impossible" for the operator to see the exact domain requested by the user, forcing a rethink of the regulatory and technical tools to combat certain illegal uses without destroying net neutrality or wiping out legitimate websites along the way.
How to enable ECH in the most used browsers
The good news is that activating or taking advantage of ECH as a user is becoming increasingly easy.because the main browsers have been incorporating native support and, in many cases, they come with it ready from the factory.
En Google Chrome:
- ECH has been supported since Chrome 117. In earlier versions, it was necessary to go to
chrome://flags/#encrypted-client-helloand activate the “Enable” option. - In recent versions, ECH is enabled by default and doesn't even appear as a configurable flag.The browser uses it automatically when the server supports it.
- The important is Enable secure DNS from
chrome://settings/securityby selecting “Use secure DNS” and choosing a provider such as Cloudflare, Google, etc.
In Mozilla Firefox:
- You need to use version 118 or later to have stable ECH support.
- En
about:configThe keys related to “echconfig” usually come in “true”, which indicates that ECH is operational in the browser engine. - Essential condition: Enable DNS over HTTPS (DoH) In Settings → Privacy & Security, at the bottom, select the protection that enables DoH. Without DoH, Firefox does not use ECH even if it is compiled into the browser.
En Microsoft Edge and Opera (Based on Chromium) the behavior is very similar to Chrome: native support since relatively recent versions and transparent use if the server allows it, provided that secure DNS is configured. Safari, for its part, has been experimenting with ECH but its support is even more limited and requires activation in advanced or experimental options.
In all cases, it's worth remembering that ECH will only be used if the server or CDN supports it.If you visit a website hosted on a traditional hosting service without ECH or a CDN that doesn't have it enabled, your browser will revert to the classic model with visible SNI.
How to check if ECH is working on your connection
Activating options is one thing, but verifying that they're actually doing something is another.To verify that ECH is active and working, there are several fairly simple online tools.
Cloudflare offers one of the most popular trialsOn their privacy diagnostics page, you can run a test that checks, among other things, whether you're using Secure DNS, DNSSEC, TLS 1.3, and Secure SNI. If the latter appears as correct, it means your browser is using ECH when connecting to compatible Cloudflare services.
In addition, Cloudflare offers text-mode tools that allow you to perform checks from terminal or automated scripts, which are very useful for system administrators who want to validate deployments without relying on a web interface. In these results, the SNI field is usually marked as “Encrypted” when ECH is active.
Other testing websites also show the ECH status through fields like “SSL_ECH_STATUS”, which should display as “Success” if the extension has been successfully negotiated. These pages typically check the TLS version, HTTP/3/QUIC usage, and other advanced parameters.
If you find that a website is not loading properly after activating ECHThere's always the option of temporarily disabling DoH or the browser's experimental flags and seeing if the problem disappears. It's not ideal from a privacy standpoint, but currently there are still servers, firewalls, and middleboxes that don't fully integrate with ECH.
Impact on parental controls, corporate filters, and performance
ECH improves user privacy, but also breaks certain traditional filtering modelsIn home or business environments, many administrators rely on systems like Pi-hole, AdGuard Home, or custom DNS filters to block malicious websites, advertising, or inappropriate content as part of their security measures. parental controls.
If the browser uses DoH directly against a third-party provider and also negotiates ECHThese "local network" filters lose much of their effectiveness: they no longer detect DNS queries or SNI. In practice, the router or the filtering server cannot decide what to block because the key information no longer passes through them or is encrypted.
Therefore, both Mozilla and Google have introduced options to enable or disable DoH and ECH. From within the browser itself, and even support exception lists or managed policies in corporate environments. This allows a company to decide whether to prioritize employee privacy or strict compliance with its internal browsing policies.
In terms of performance, ECH involves a little more cryptographic workThe ClientHelloInner needs to be encrypted and decrypted, ECH public keys need to be handled, etc. On modern equipment, this represents an almost imperceptible overhead, but on very old or very resource-constrained devices, it could add some latency to the connection establishment.
The reality is that TLS 1.3, QUIC, and modern optimizations more than compensate for that small extra cost.TLS 1.3 requires fewer round trips to establish a connection, QUIC reduces latency at the transport level, and overall, browsing ends up being faster than with older TLS 1.2, even with ECH added to the equation.
Practical advantages and disadvantages of activating ECH
Among the main advantages of ECH, several very clear ones can be highlighted.:
- Enhanced privacy against network operators and observersThe domain you're accessing no longer travels in plain text within the SNI. Intermediaries can no longer easily monitor or profile which websites you visit simply by looking at the TLS handshake.
- It makes selective website blocking more difficult.Systems that rely on reading the National Information System (NIS) to apply censorship or access restrictions are no longer working. This forces the use of more complex, expensive, and less precise methods if content filtering is to continue.
- Compatibility with existing security infrastructureECH does not require redesigning TLS or discarding servers. It is implemented as an extension in browsers, web servers (Nginx, Apache, etc.), and CDNs. Simply update your software and enable the relevant options.
But there are also disadvantages and limitations that should not be ignored.:
- Incomplete compatibilityNot all servers, TLS libraries, and security tools yet support ECH. This can lead to connection failures, unusual errors, or strange behavior while adoption continues to mature.
- Need for updates and maintenanceFor ECH to remain effective, browsers, servers, DNS resolvers, and CDNs must be kept up to date. It's not a "turn it on and forget it" situation; there will be key changes, configuration adjustments, and new versions of the standard.
- Increased processing loadEven if small, the additional encryption of the handshake adds work for both the client and the server. In very high traffic environments or hardware very limited, it may be a factor to consider.
- Adoption still limitedAlthough giants like Cloudflare, Mozilla, and Google are pushing hard, many platforms and services still don't speak "ECH natively," which reduces their overall impact in the short term.
In any case, for most users the advantages far outweigh the disadvantages.If you don't rely on local DNS-based parental controls or classic corporate filters, enabling ECH and DoH is often a very good idea to gain privacy without sacrificing convenience.
Looking at the big picture, ECH is the last major brick missing from the wall of web encryption.TLS 1.3 brings security and speed, QUIC accelerates connections, DoH and DoT hide DNS queries, and ECH finally closes the SNI and ClientHello "window." The TLS protocol had been plagued by this metadata leakage for years, and the collaboration of the IETF, major CDNs, and browsers has allowed for the design of a robust solution that, although still being refined, clearly points the way toward an internet where it is increasingly difficult to snoop on which websites you visit without directly breaking the connection or violating the law.
Passionate writer about the world of bytes and technology in general. I love sharing my knowledge through writing, and that's what I'll do on this blog, show you all the most interesting things about gadgets, software, hardware, tech trends, and more. My goal is to help you navigate the digital world in a simple and entertaining way.