Home Books Training Newsletter Resources
Sign up Log in

Cryptography & Security Newsletter

136

ECH Is Done, But Can We Make It Work?

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.

ECH Adds Confidentiality to TLS Handshakes

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’s Powerful Enemies

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.

We’re Not There Yet

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.

Safety in Numbers

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?

Subscribe to the Cryptography & Security Newsletter

This subscription is just for the newsletter; we won't send you anything else.

Short News

PQC

  • Coinbase's Independent Advisory Board on Quantum Computing and Blockchain publishes its first position paper, concluding that a CRQC is at least a decade away but that wallet-level signature schemes are the primary vulnerability, with an estimated 6.9 million BTC already exposed, and urging blockchains to begin post-quantum migration now.
  • Scott Aaronson reports on two quantum computing breakthroughs from Caltech and Google that dramatically reduce the qubit count needed to break elliptic curve cryptography, making Bitcoin signatures vulnerable to quantum attack far sooner than previously thought.
  • Marin Ivezic argues that three papers published in March 2026—from Google, Oratomic/Caltech, and INRIA—collectively reduce the qubit requirements to break elliptic curve cryptography by orders of magnitude, and that combined with silicon quantum computing completing its fault-tolerance checklist and the U.S. intelligence community elevating quantum to a tier-1 threat, organisations can no longer delay PQC migration.
  • Bitcoinist reports that Ethereum Foundation researcher Will Corcoran outlined a post-quantum security roadmap at the Institutional Ethereum Forum, centred on a STARK-based signature aggregation scheme called LeanSig that compresses validator signatures by roughly 250x to make quantum-resistant consensus viable without sacrificing decentralisation.
  • Symbolic Software introduces Crucible, an open-source conformance testing framework for post-quantum cryptographic implementations (ML-KEM and ML-DSA) built from real audit findings, which found two minor gaps across 15 major libraries but no security vulnerabilities.
  • NIST is seeking public comment on a draft FIPS 205 extension that defines six new SLH-DSA parameter sets optimised for fast verification and smaller signatures in software/firmware signing, at the cost of a hard limit of 2^24 signatures per key.
  • Filippo Valsorda argues that Grover's algorithm does not threaten AES-128 or other 128-bit symmetric keys, and doubling key sizes for post-quantum safety is unnecessary churn.
  • Filippo also writes that recent quantum computing progress has shortened CRQC timelines enough that pure post-quantum ML-DSA authentication must be deployed now rather than waiting for protocol adaptations or hybrid schemes.
  • Scott Aaronson reflects on the recurring pitfalls in quantum debates, covering black-and-white thinking, hype-meter reductionism, and confused premises that derail non-expert conversations about quantum computing.
  • Filippo Valsorda and Matthew Green set up a public charitable long bet, open for third-party back bets, on whether ML-KEM-768 or X25519 breaks first by 2040.
  • Marin Ivezic surveys the latest quantum risk landscape, covering Q-CTRL's heterogeneous architecture cutting RSA-2048 to under 381,000 qubits, Cloudflare joining Google on a 2029 PQC deadline, photonics' first below-threshold result, and a capstone arguing China could win the quantum race.
  • The PKI Consortium opens registration for its PQC Conference in Amsterdam on December 1-3, 2026, billed as the largest dedicated PQC event to date with a focus on real-world implementation.
  • Cisco Research surveys PQC migration status across nine protocols, finding TLS and Signal lead with hybrid key exchange deployed while DNSSEC and BGP face the most structural barriers from large post-quantum signature sizes.
  • Jean-Philippe Aumasson announces a major update to the awesome-post-quantum list, adding cleaner standards and migration guidelines, more national guidelines, IETF documents, and tech company contributions.
  • Samuel Jaques of the University of Waterloo annually updates a quantum hardware progress chart mapped against thresholds needed to break RSA and ECC, with the 2026 edition analysing new bicycle/LDPC code architectures that reduce qubit requirements while concluding that post-quantum migration remains urgent.
  • Meta's Rafael Misoczki, Isaac Elbaz, and Forrest Mertens present Meta's PQC migration framework, introducing five PQC Migration Levels (PQ-Unaware through PQ-Enabled) and sharing lessons on prioritization, cryptographic inventory, external dependencies, and hybrid deployment from their ongoing company-wide migration.
  • The Quantum Insider reports that Project Eleven awarded its Q-Day Prize to Giancarlo Lelli for breaking a 15-bit elliptic curve key on quantum hardware using a variant of Shor's algorithm, extending prior public demonstrations of quantum attacks on ECC.
  • Craig Gidney argues that the Q-Day Prize was fundamentally flawed, and the winning submission that "broke" a 15-bit ECC key would have yielded identical results using a random number generator, demonstrating nothing about actual quantum progress.

Cryptography

  • Prossimo reports that Rustls remains the fastest TLS library in Q1 2026 benchmarks against OpenSSL and BoringSSL, and previews a split-mode feature in Rustls 0.24 that could roughly double per-connection throughput.
  • Red Sift tests 19 major mailbox providers and finds only 47% validate Ed25519 DKIM signatures, with Gmail, Microsoft 365, and Yahoo lacking support, while six providers still accept cryptographically broken sub-1024-bit RSA keys.
  • QuantumVillage releases the Entropy Loop, a $35 open-source quantum random number generator built from a Raspberry Pi Pico and fiber optics that passes NIST STS 2.1.2 validation.
  • OfficeChai reports that HSBC India stored passwords in plaintext, exposed when the bank emailed customers asking them to type their existing passwords in uppercase rather than resetting them.
  • OSTIF shares results of security audits of DEfO, the Encrypted Client Hello (ECH) implementation for OpenSSL, conducted by Ada Logics and 7ASecurity, uncovering 15 findings including 3 high-severity issues, with ECH now merged to OpenSSL's master branch ahead of the OpenSSL 4.0 release.

Privacy

  • PanicLock, by seanieb, is a macOS tool that instantly disables Touch ID when the lid closes, forcing password-only unlock to protect against coerced biometric access.
  • Trail of Bits describes its pre-launch audit of WhatsApp's Private Processing, the system that enables features like AI summarization inside AMD SEV-SNP and NVIDIA confidential GPU enclaves.
  • Joseph Cox of 404 Media reports that the FBI recovered Signal messages from an iPhone via the internal notification database even after the app had been deleted.
  • Jeremia Jay Schouten warns that Signal messages persist in iOS notifications for months in the push notification database (as shown in a recent FBI extraction case) and recommends disabling notification previews to mitigate the leak.
  • Fairlinked e.V.'s BrowserGate campaign documents that LinkedIn covertly scans users' browsers for over 6,000 installed products, including extensions revealing religious beliefs and competitor product usage, sharing results with third parties without user knowledge or legal basis.
  • The Citizen Lab exposes two covert telecom surveillance actors exploiting SS7 and Diameter signalling vulnerabilities to track targets globally, identifying 019Mobile (Israel), Airtel Jersey/Sure, and Tango Networks UK as recurring surveillance gateways, with one campaign deploying a SIMjacker-style SMS exploit to silently extract location data from SIM cards.
  • Apple outlines UK-specific age verification requirements for Apple Accounts, requiring adults to confirm they are 18 or older via credit card or approved ID before accessing certain services, with web content filters automatically applied to those who have not confirmed their age.

PKI

  • Let's Encrypt's Matthew McPherrin explains why maintaining test sites with broken TLS requires custom tooling, and details the Go program built to solve the problem.
  • Filippo Valsorda announces sctdata.geomys.org, a dashboard showing the distribution of embedded SCTs across CT logs by CA, revealing that only Let's Encrypt spreads load evenly across Usable logs.
  • Stephen Davidson quantifies the overlap between eIDAS Trusted Lists and CCADB, identifying 132 active QWAC subCAs across 48 TSPs with roughly half operating outside the WebPKI.
  • Brian Trzupek introduces DigiCert's MTC Playground, an experimental end-to-end implementation of Merkle Tree Certificates featuring a full ACME server, Merkle tree visualization dashboard, and ML-DSA cosigning.
  • Stephen Davidson finds that only 33 of 64 eIDAS QWAC CAs present in the CCADB are trusted across all four major browser root stores, reflecting the fragmented browser trust of Qualified TLS.
  • DigiCert reports in a Mozilla CA compliance bug that a malware attack on a support team member allowed a threat actor to obtain initialization codes for a limited number of code signing certificates, some of which were used to sign malware, with all identified certificates revoked within 24 hours.
  • Let's Encrypt's Matthew McPherrin describes the CA's 2026 mass-revocation simulation, using a theoretical DNS-01 authorization reuse violation as the scenario, with staging issuance halted and ARI used to signal affected clients to renew immediately.
  • SSL.com reports a Mozilla CA compliance bug in which a flawed MPIC implementation in EJBCA caused DCV to complete using only remote network perspectives without the primary, affecting approximately 1.77 million certificates that were all revoked within 24 hours.
  • Adriano Santoni notes that Firefox 150 now displays a QWAC indicator referencing Regulation (EU) 2024/1183, but argues the absence of the EU Trust Mark may not satisfy Commission Implementing Regulation (EU) 2025/2527, which takes effect January 2027.

Other

  • Google's Chrome team explains how Device Bound Session Credentials (DBSC), now rolling out on Windows in Chrome 146, cryptographically ties authentication cookies to a device's secure hardware so that stolen cookies become worthless to attackers.
  • Andy Greenberg of WIRED reports that SentinelOne researchers decoded Fast16, a 2005 sabotage malware predating Stuxnet that silently corrupts engineering simulation calculations and may have targeted Iran's nuclear program.

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.

Find out More

@feistyduck

Books

  • Apache Security
  • Bulletproof TLS and PKI
  • ModSecurity Handbook
  • OpenSSL Cookbook

Training

  • Practical TLS and PKI

Resources

  • Newsletter
  • SSL/TLS and PKI History
  • Bulletproof TLS Guide

Company

  • Support
  • Website Terms of Use
  • Terms and Conditions
  • Privacy Policy
  • About Us