30 April 2026
Feisty Duck’s Cryptography & Security Newsletter is a periodic dispatch bringing you commentary and news surrounding cryptography, security, privacy, SSL/TLS, and PKI. It's designed to keep you informed about the latest developments in this space. Enjoyed every month by more than 50,000 subscribers. Written by Ivan Ristić.
Some technologies are easier to deploy than others. Take TLS, for example. Once enough time passes and we upgrade the servers and clients, we’re done. Encrypted Client Hello (ECH) is not one of those technologies. To get it to be effective, we first need to go through the usual upgrade cycle, iron out the last kinks, and then also get enough of the ecosystem to opt in to achieve safety in numbers.
If you’re not already familiar with ECH, here’s a very quick recap: TLS, like most encryption protocols, starts with an unencrypted handshake that negotiates encryption parameters. After the handshake, the traffic has the benefit of authentication, confidentiality, and integrity. Having unencrypted information traveling over the network reveals data that can be used for fingerprinting. In TLS, the handshake also includes the identity of the intended destination domain name. That’s not great for privacy, and it’s the problem ECH wants to solve. ECH creates another layer of static encryption that doesn’t need to be negotiated; the only purpose of this new layer is to protect the handshake that follows. A fake, visible handshake remains, but it doesn’t contain any identifying information (or at least it shouldn’t). If you want more technical details, head over to our July 2025 newsletter.
After eight years in development and testing, ECH was recently declared done and published in RFC 9849 (the main document) and RFC 9848 (bootstrapping via DNS). The major browsers support ECH, which means that the coverage on the client side is very good. (Check your browser here.) On the server side, it’s only supported by Cloudflare at this point, but Cloudflare is quite a popular CDN fronting millions of websites.
The server-side adoption will take longer. OpenSSL, which powers the vast majority of servers, just gained support in version 4.0, but it will take a while for this release to be propagated to various operating systems. That’s a process that will take some years, although you can experiment with it today if you wish. The just-released Nginx 1.30.0 supports ECH, so you could deploy it with a custom-compiled version of OpenSSL.
Privacy has very powerful enemies. On one end of the spectrum, we have governments that engage in censorship and internet connectivity shutdown to restrict information flow and freedom of speech. The initial testing and deployment of ECH a couple of years ago caused a strong reaction from Russia, for example. It showed that ECH is indeed very much needed. The internet is routinely censored even in countries that we perceive as democratic. In Spain, for example, major parts of Cloudflare’s network don’t work whenever a football match is on. There’s a similar problem in Italy as well.
On the other end of the spectrum, we have enterprises that want to or need to observe and control all their network traffic. Although their reasons may be legitimate, their current implementation relies heavily on being able to observe unprotected TLS handshakes. Vendors who build products designed for traffic monitoring and interception have been looking for a way to maintain the necessary functionality. Cisco’s documentation, for example, has a thorough explanation of the problem and possible workarounds. You can find plenty of other similar documents by searching for “how to block ECH” online. A successful strategy might involve full control of DNS so as to strip the ECH bootstrapping information and TLS interception via a custom root certificate.
The main premise of ECH is blending in, which means that a website that relies on it can’t be distinguished from other websites from the network traffic alone. Most of this is achieved by ensuring that all TLS handshakes look the same from the outside, no matter whether ECH is used. Although that tech is now designed and deployed, one unambiguous signal remains that can be used for filtering; when ECH is used, the domain name of the intended website is replaced with a static domain name specifically allocated for this purpose. For Cloudflare, for example, it’s cloudflare-ech.com.
At present, it’s quite easy to observe this domain name when it appears on the network and drop the associated TCP connections. There is a technical explanation for this, and it comes down to the fact that user agents need to recover from having stale configuration data. Because the real destination is hidden with encryption, if stale encryption is used, the server can’t tell where the user wants to go. Further, even if the server has access to the up-to-date encryption information, clients need a way to trust that information. We don’t want active network attackers to be able to break ECH. Nick Sullivan has a blog post that goes into the technical details, with a proposal outlining how this can be fixed.
The last remaining problems will be ironed out, but the real challenge is figuring out how to use ECH to hide in the crowd. This problem comes in two parts. First, the outer TLS handshake has to carry a domain name—so that it looks like the client is not accessing an ECH-enabled website—but what domain will it be? We know it can’t be something that’s static and known, because then blocking ECH connections will remain easy. The ideal solution would be to enable browsers to somehow pick a name at random from all domains hosted by the same provider.
However, connecting to an ECH-enabled website requires some bootstrapping configuration, which may not be easy to obtain in contested environments. In a nutshell, plaintext DNS can be and is forged to remove ECH, while the usage of secure DNS resolution methods (such as DNS-over-HTTPS, or DoH) is prevented. Without DNS, nothing works, so the only option is to use a censored DNS server. A case for peer-to-peer DNS resolution?
This subscription is just for the newsletter; we won't send you anything else.
We sometimes use Anthropic’s Claude to help us create short news summaries.
Designed by Ivan Ristić, the author of SSL Labs, Bulletproof TLS and PKI, and Hardenize, our course covers everything you need to know to deploy secure servers and encrypted web applications.
Remote and trainer-led, with small classes and a choice of timezones.
Join over 3,000 students who have benefited from more than a decade of deep TLS and PKI expertise.