Cryptography & Security Newsletter

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.

How Does ECH Work?

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. In that case, the best the adversary can do is drop the responses for HTTPS DNS record. For best results, you'd need to use a DNS provider you can trust—for example, by using DNS over HTTPS (DoH).

Do We Have Privacy Now?

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).

An interesting aspect of ECH is that it changes the TLS handshake even when it's not used. This is done via a dummy ECH extension that's used if there is otherwise no need for ECH. This is called GREASE ECH.

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.

Update (5 October 2025): Updated the text with mention of GREASE ECH, which I missed on my first reading of the ECH RFC. Thanks to Matt Holt for flagging my mistake.

Short News

• The Opossum attack (application layer desynchronization using opportunistic TLS) against TLS targets applications that support implicit TLS and opportunistic TLS at the same time.
• Peter Gutmann, a professor of computer science at the University of Auckland New Zealand, and Stephan Neuhaus of the Zurich University of Applied Sciences, make fun of the post-quantum migration, using “VIC-20 8-bit home computer from 1981, an abacus, and a dog.”
• Let's Encrypt has announced the issuance of its first IP address certificate, a long-requested feature that will gradually become available to subscribers, providing an alternative to traditional domain name certificates for specific use cases.
• Phoenix R&D experimented with merging the Transport Layer Security (TLS) and Messaging Layer Security (MLS) protocols into a new hybrid protocol, with the goal of overcoming the limitations of TLS 1.3 concerning long-running connections, post-quantum security, and X.509 certificates.
• Starting August 1, 2025, Google Chrome will no longer trust digital certificates from Chunghwa Telecom and Netlock for new TLS certificates, due to a history of concerning behavior and noncompliance.
• There is a new iteration of Merkle Tree Certificates, also known as Photosynthesis, a new design that integrates Certificate Transparency directly into the certificate issuance process to improve efficiency and mitigate the size impact of post-quantum keys and signatures.
• The OpenSSL Conference will be held this October in Prague.
• rxtls is a high-performance Certificate Transparency (CT) log processor.
• ctail is another tool for CT processing, designed for quickly tailing the head of the logs.
• The Go programming language has introduced the FIPS 140-3 Go Cryptographic Module, providing native FIPS 140 support built into the standard library, which makes it easier and more secure for Go users to achieve FIPS 140 compliance.
• A critical memory leak vulnerability, CVE-2025-5777 or Citrix Bleed 2, affects Citrix NetScaler devices. It allows remote attackers to easily extract sensitive memory data and requires immediate patching.
• The CA/Browser Forum's Ballot SMC013 proposes enabling the use of NIST-standardized post-quantum cryptography algorithms, ML-DSA and ML-KEM, in S/MIME certificates to allow certificate issuers to conduct experiments.
• Ryan Hursts presents a market analysis of WebPKI, comparing insights from Mozilla telemetry data and Certificate Transparency data regarding certificate authority usage and issuance.
• Between March and December 2024, Salt Typhoon extensively compromised a US state’s Army National Guard network. This is why we need end-to-end encryption.
• ghostcrew wrote a Model Context Protocol (MCP) server to connect AI to crt.sh for purposes of subdomain discovery. This is not what the Sectigo-maintained public database of certificates has been designed to do, and it’s only going to add to its performance problems.
• The Bluesky Team announced its collaboration with the UK government on age-assurance measures for the Online Safety Act, detailing upcoming age-verification and content restrictions for UK users under eighteen or those unverified. However, Bluesky doesn’t want to implement the verification itself; the team is passing users onto Epic’s service, which will be amassing UK citizens’ private data. I don’t know what’s more depressing: the UK government’s requirement for age verification or Bluesky’s implementation.
• Colm MacCárthaigh explains the establishment of a European trust service provider (EU-TSP) for the AWS European Sovereign Cloud, which will autonomously manage certificate authority key materials and issuance to ensure secure network communications.
• Sam Bent talks about acoustic side-channel attacks.
• Fighting the performance issues that have plagued its CT logs, Sectigo implemented CF_CTile, a caching proxy that runs on Cloudflare.
• Speaking of performance, two new so-called static CT logs have been approved for inclusion in Chrome. They’ll enter use in about 70 days. Static CT logs are the next evolutionary step from RFC 6962 logs, designed for better performance and reduced operational costs.
• The Digicert Yeti 2025 CT log has died.
• Filippo Valsorda ported the age encryption to Typescript. This enables it to run in a browser, which—in turn—makes it possible to encrypt with passkeys.
• IPng Networks has published the first article in a series covering how to run a CT log server.
• In the EU, Chat Control is again on the agenda, after Denmark took over the EU Presidency. The next vote might take place in October 2025. Back in June, the EU Commission presented its ProtectEU roadmap, which aims to provide a decryption backdoor by 2030.