31 July 2025
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ć.
TLS 1.3, which took about five years to complete and was released in 2018, changed everything. Starting with a two-decade legacy of cruft, the designers brought modern cryptography to TLS while maintaining backward compatibility. As a result, the upgrade process was smooth and most network traffic is now well-protected. Today’s operators no longer have to wrestle with a bazillion TLS configuration options; TLS 1.3 is just boringly secure.
However, in the rush to get new encryption out there, the TLS 1.3 protocol designers decided to leave some features behind. Although improvements were made to allow encrypting parts of the TLS handshake (most importantly, the client and server certificates), some key aspects, such as the identity of the destination server, remained in plaintext. It took a further seven years and twenty-five revisions to solve this problem, but it’s now been done: Encrypted Client Hello (ECH) has now been approved by the TLS working group and is in the process of being officially published as an RFC.
As a reminder, the core problem is that encryption can take place only after the parties agree on the various cryptographic options. Some information just has to be sent in plaintext, and the intended server identity is one of them. So ECH really needed to be able to figure out at least some of the encryption parameters before sending even the first TLS packet.
The solution was found in placing special ECH encryption keys in DNS—more specifically, in the SVCB or HTTPS resource records. These records are fairly new (RFC 9460 was published in November 2023) and also took a long time to complete: six years. Like with ECH, a lot of thinking went into designing a solution that would work in the real world. The keys are designed to support the transport of a variety of connection parameters. The base specification supports parameters for ALPN as well as IPv4 and IPv6 address hints. Because the design is extensible, ECH added its own parameter in there.
Here’s an example of an HTTPS DNS resource record (taken from the configuration of cloudflare-ech.com):
1 . alpn=h3,h2 ipv4hint=104.18.10.118,104.18.11.118 ech=AEX+DQBB8QAgACA3XKkVgGIAo4hJHplVuWsZBtekdlMq4qznpgFkewwSQAAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:0:0:0:0:6812:a76,2606:4700:0:0:0:0:6812:b76
The fact that DNS is used for this purpose can be a little tricky, because DNS itself isn’t protected most of the time. DNSSEC, which offers protection, isn’t widely used, but those who want to use ECH can enable it. Alternatively, privacy-focused users can get their information encrypted from a trusted third party—for example, by using DNS over HTTPS (DoH).
At this point, we have ECH supported in major browsers on the client side, and one major content delivery network (CDN)—Cloudflare—on the server side. We have the technical tools, but we need to wait to see how things will play out. When Cloudflare activated ECH in late 2024, some countries took note. In November 2024, Russia complained that ECH was illegal and started to block it. China is also known to be monitoring and interfering with encrypted traffic, including ECH (and its predecessor, ESNI).
Thus, we end up in a situation in which authorities cannot see what websites you’re visiting, but they can observe that you’re attempting to use ECH. This could conceivably be risky in some situations, because you’re effectively making yourself known to the authorities. Also, when blocking is in place, you can’t actually visit the sites you want to access.
There is also the separate problem of a variety of other organizations relying on having visibility into the TLS handshake. Corporate networks come to mind, as do parental controls. It’s the dreaded middleboxes problem.
Can we solve this? I suppose we could, if ECH became ubiquitous and appeared in every single TLS connection. We have to remember that the goal of ECH is not necessarily to bypass censorship but to improve privacy for the entire world. People outside Russia and China also need privacy, but we don’t currently necessarily have it. But we want it.
This subscription is just for the newsletter; we won't send you anything else.
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 2,000 students who have benefited from more than a decade of deep TLS and PKI expertise.