mailwal

eMudhra: Free Certificates for Everyone

Feisty Duck Newsletter
Feisty Duck

Cryptography & Security Newsletter

3 November 2026
142

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

eMudhra: Free Certificates for Everyone

Every analysis of public trust on the internet involves discussing its biggest weakness: any CA can issue a certificate for any domain name without the owner's permission. For about 20 months, because of a mistake by one of the public CAs, anyone could issue certificates for any domain name. If you thought DigiNotar was bad in 2011, this is worse.

eMudra Botches Intermediates and No One Notices

In April 2025, a public CA called eMudhra botched a batch of intermediate certificates and ended up with eight trivially weak private keys. So weak, in fact, that anyone could and still can recover them with only a modest effort. Rather than selecting large, unpredictable values, they used one of only 256 possibilities for each key. Brute-force attacks are very effective with such a small number of possibilities.

This was in 2025, and no one complained about these certificates. A lone security researcher—Wayne—did, but only in October 2026. They used the paranoid_crypto tool to review the database of all known public intermediates, and eMudhra’s certificates stood out. After discovering the problem, they reported it to Mozilla and other leading root stores, and now we're here.

Why is this worse than past incidents? Let’s look at the past. A conceptually similar incident occurred in 2008, when researchers exploited a weakness in MD5 to obtain a working intermediate. In that instance, the researchers acted responsibly and destroyed the backing key. In 2011, a public CA called DigiNotar was completely compromised. At least 500 certificates were issued, and 300,000 users were attacked, but at least only one attacker (or group) had control. With this recent problem, anyone can mint certificates from the botched intermediates, because anyone can find the backing keys.

Let’s take a look at what worked and what didn’t.

What worked?

Here are some things that worked:

  • Open source worked. Some people at Google created the paranoid_crypto tool and made it open source. Because the tool had been available, someone used it, and the problem with eMudhra was uncovered. (Interestingly, the tool repository had been archived in August 2026. At the time of writing, it’s again active.)
  • Because of CT, we know that there were no unauthorized Web PKI certificates. However, we know this only because CT showed no certificates at all from these botched intermediates. If eMudhra were a big CA (e.g. with millions of certificates), it would have been difficult or impossible to distinguish what was authorized and what wasn’t.
  • Interestingly, after discovering the weakness, CT logs were reconfigured to reject submissions from the botched intermediates. At first I thought—how disappointing. However, thinking about it some more, I realized that CT has this interesting property: a handful of CT log operators can block issuance of any certificate. In this instance, it was for the good. With the botched intermediates blocked, it’s now no longer possible to issue a fraudulent Web PKI certificate from them—good news for everyone except those operating in the Internet PKI ecosystem, which ignores CT.
  • Proprietary revocation mechanisms largely worked as designed. Chrome, Firefox, Microsoft, and Safari users were protected. (If you’re not familiar, because standard certificate revocation mechanisms don’t work, browser vendors implement their own—emergency-style—mechanisms. If you hear things such as CRLSets, CRLite, OneCRL, and valid, they’re referring to that functionality.)

What didn’t work?

Some important things didn’t work:

  • With so much scrutiny of public PKIs in the last decade, this is the type of problem that should have been discovered immediately. We have a system called the Common CA Database (CCADB) that discloses all root and intermediate certificates. Google had the right idea with their paranoid_crypto tool, but they weren’t using it against CCADB. (To be clear, detecting private keys isn't trivial, and not all weaknesses can be detected without access to the private keys, but this one could have been.)
  • Unsurprisingly, the standard revocation mechanisms didn’t do much. I checked one of the intermediates and observed both CRL and OCSP revocation information, but is anyone checking those these days? We know that the browsers don’t, but at least they have their own proprietary ways. For everyone else, for example, using curl on the command line, or various programming languages… these intermediates were (and still are, in many cases) as good as new.
  • We know that there have been no misissued certificates in Web PKI, thanks to Certificate Transparency (CT). Unfortunately, plenty of systems out there don’t do CT. For all we know, exploitation had been taking place, silently, for months. If the intelligence services didn’t know and hadn’t been exploiting this problem the entire time, they’re kicking themselves now.
  • The proprietary mechanisms worked, but they have rough edges. For example, Apple struggled to block the offending certificates consistently. If you’re in their ecosystem, you may need to act now to stay safe, as I had to do. Check out this website for the best information.

Aftermath

After the discovery, eMudhra exited the TLS certificate space. Good. No doubt they would have been evicted anyhow. Google expanded its security checks of intermediates to all certificates recorded in CCADB, so hopefully this particular problem won’t ever happen again. (Interestingly, their paranoid_crypto tool had been in use against the certificates in CT… but didn’t detect anything because eMudhra never issued certificates from these intermediates.)

Standard revocation didn’t work, but you already knew that. It’s hard to know how many user agents remain vulnerable, but this Cloudflare blog post shares useful measurements from two weeks after the discovery. We’re left with a gaping hole in Internet PKI that anyone with means can exploit. If you’ve recently been worried about “harvest now, decrypt later,” you now have another problem: “harvest now, decrypt now.” Individuals (using browsers) are safer than others, but machine-to-machine communication is at high risk.

Short News

Post-Quantum Cryptography

  • The German BSI has issued an advisory against using Classic McEliece for new cryptographic projects due to recent cryptanalysis progress, though no practical attacks currently exist against the parameter sets in TR-02102-1. The agency is monitoring ongoing developments in this post-quantum cryptography scheme.
  • A practical guide for developers on post-quantum cryptography recommendations, with specific algorithms and implementations for encryption, key exchange, signatures, and other cryptographic operations. The guide emphasizes that the post-quantum transition is expected to complete by 2029 and provides concrete cheat sheet recommendations including ML-KEM-768 for key exchange, ML-DSA-44 for signatures, and HPKE with post-quantum hybrid approaches.
  • Coinbase proposes a collaborative, multi-year approach to prepare Bitcoin for post-quantum cryptography migration. The strategy emphasizes early preparation, a modular container design to gradually introduce quantum-resistant signature schemes, broad community engagement, and comprehensive transition planning that protects all types of Bitcoin holdings and custody workflows.
  • Article discusses the migration of SSH to quantum-safe cryptography, covering the vulnerability to store-now-decrypt-later attacks, current adoption rates (12% of internet-facing SSH servers support PQC as of May 2026), and practical migration strategies. It explains the two-part migration process: key exchange (which can be upgraded automatically using hybrid approaches like mlkem768x25519-sha256) and authentication/signatures (which requires manual deployment of hybrid host keys and user key replacement). The article provides guidance on prioritizing key exchange upgrades first while planning for eventual signature migration and cleanup of obsolete classical keys.
  • This draft proposes nine post-quantum TLS 1.3 key exchange algorithms based on HQC-KEM (Hamming Quasi-Cyclic Code-based KEM), a NIST-standardized post-quantum algorithm. It defines three standalone variants (HQCKEM128/192/256) and six hybrid variants combining HQC-KEM with classical algorithms (X25519, X448) or ML-KEM. The hybrids provide algorithmic diversity against quantum threats, with HQC-KEM offering different hardness assumptions than lattice-based alternatives.
  • A draft specification defining two composite post-quantum signature schemes for SSH that combine ML-DSA with traditional Ed25519 or ECDSA (P-384) signatures. The schemes use identifiers ssh-mldsa44-ed25519 and ssh-mldsa87-p384, with keys and signatures constructed as concatenations following a composite signature framework. Signatures incorporate a message representative with fixed prefix, domain-separation label, context string, and SHA-512 hash of the message.
  • MIKE (Module Isogeny Key-Exchange) is a post-quantum non-interactive key exchange mechanism based on isogeny cryptography, offering the smallest public and secret keys among PQ KEMs. It provides two parameter sets (Fast and Rigorous) across NIST security levels I, III, and V, with implementations in C, Rust, and Python/SageMath.

Cryptography

  • A team from Anthropic successfully solved the long-standing bounty to determine how NIST elliptic curve seeds (P-192, P-224, P-256, P-384, P-521) were generated. They discovered the seeds were created by seeding the POSIX drand48 RNG with UNIX timestamps from 1997-1998, rather than through the previously claimed hashing method. The team donated the $12,288 prize to ISRG/Let's Encrypt, tripling it to $36,864. The analysis found roughly twice as many valid seeds as published and confirmed that mainstream cryptanalysis has not revealed practical weaknesses in these curves.
  • The article addresses common conspiracy theories about NSA/NIST involvement in cryptography, arguing that most such theories lack technical merit. It reviews the history of NSA and NIST's role in cryptographic standardization, examines popular rumors including post-quantum backdoors, and explains why these conspiratorial claims are generally unfounded. The author distinguishes between legitimate political concerns about NSA secrecy and technically baseless fears, while acknowledging the NSA's inherent role in classified operations.
  • NIST SP 800-185 Rev. 1 specifies four SHA-3-derived cryptographic functions (cSHAKE, KMAC, TupleHash, and ParallelHash) for 128- and 256-bit security levels. The revision introduces a new streaming interface (INIT, ABSORB, SQUEEZE) enabling incremental processing of input and output without requiring advance knowledge of total lengths, while maintaining backward compatibility with single-call interfaces from the previous version.
  • Trail of Bits introduces SequenceHash, a hash-agnostic multihashing construction that works with any secure hash function (SHA-256/384/512, BLAKE, RIPEMD, etc.) to prevent ambiguous input encodings. It provides length-extension protection through double-hashing, supports optional customization strings for context-binding, and includes SequenceMAC as a keyed variant. The construction is simpler than NIST TupleHash while offering equivalent security protections, with implementations in Rust, Go, and Python.
  • TLSGatekeeper is a network-based tool that enforces secure TLS configurations at scale by monitoring and validating TLS handshakes against security policies. The authors analyzed over 50 million TLS handshakes against national guidelines, finding widespread use of non-recommended configurations and rapid adoption of post-quantum cryptography options like X25519MLKEM768. The tool addresses the gap between security guidelines and real-world implementations by allowing servers to enforce TLS parameter policies without requiring individual client configuration.
  • OpenSSL 4.1.0 is a feature release adding DTLS 1.3 support (RFC 9147), GREASE support (RFC 8701), IKEV2 KDF support, and performance optimizations for ML-DSA, ML-KEM, and AES operations on various architectures. The release includes platform target changes, new build configurations for MSVC 2013, and initial Elbrus2000 architecture support, along with several known issues related to DTLS 1.3 KeyUpdate and handshake handling.
  • The article demonstrates a security vulnerability in C2PA (Content Credentialing for Pan-Organized Architecture) where large byte-range exclusions in signatures allow attackers to modify content after signing while maintaining valid signatures and timestamps. This enables post-signature tampering of files like images without breaking verification, and current tools don't flag this as problematic. The author advocates for stricter, format-specific exclusion rules and verifier enforcement.

Privacy and Society

  • The Citizen Lab reports that Pegasus spyware was used to target the iPhone of Serbian pro-democracy figure Vladan Đokić via zero-click exploit, and that prosecutor Rade Bajić received Apple Threat Notifications indicating mercenary spyware targeting. The investigation documents widespread spyware attacks against Serbia's pro-democracy movement during 2024-2026 anti-corruption protests, with at least 16 civil-society members confirmed as targeted or infected.
  • German police have adopted a technique called 'messenger monitoring' that accesses messaging app accounts by linking police-controlled devices to suspects' or witnesses' accounts through features like WhatsApp Web and Signal Desktop, without breaking end-to-end encryption. Access is obtained via physical device access or intercepted verification codes, allowing police to read message histories. The practice became formalized around August 2025, though its legality remains contested by privacy advocates.
  • Quad9 announces it will cease offering its free DNS-based cybersecurity service to French users starting November 24 due to a French court ruling requiring domain blocking. The organization refuses to comply with the blocking order as it conflicts with its privacy mission, and will instead withdraw service from France rather than implement the mandated censorship.
  • Browser fingerprinting is a tracking method that creates unique or near-unique identifiers from network data (IP, User-Agent, Accept-Language) and device characteristics (GPU/CPU, memory, display, fonts, extensions). Unlike cookies, fingerprints persist even when cookies are blocked. Privacy-focused browsers like Brave, Tor, and Mullvad mitigate fingerprinting through noise injection or standardization. The article discusses implications for user privacy and data monetization.
  • The Electronic Frontier Foundation has released Privacy Badger, its free tracker-blocking browser extension, for Safari on macOS (Safari 26.5+). The extension automatically blocks hidden online trackers and complements Safari's built-in privacy features. Privacy Badger now has over 4 million users and is available across all major desktop browsers.

Public Key Infrastructure

  • Chrome describes its response to DNS hijacks of .gh, .sl, and .as ccTLDs where attackers obtained unauthorized HTTPS certificates for Google domains and others. Chrome blocked the certificates via CRLSets and worked with CAs for revocation. The article recommends domain owners monitor Certificate Transparency logs, publish restrictive CAA records, and implement ACME account bindings to limit certificate issuance after DNS restoration.
  • Cloudflare announces plans to become a public certificate authority, including acquiring an established root from GlobalSign for immediate broad device compatibility, applying for inclusion in major root programs, supporting post-quantum certificates, and implementing ACME-first automation with redundancy to provide a reliable alternative to existing CAs like Let's Encrypt.
  • RPKI (Resource Public Key Infrastructure) adoption has grown significantly, now protecting 70.3% of routed internet prefixes, up from 54% a year ago. The increase is driven by countries like China (83% valid routes) and improved IPv6 adoption in RPKI (~79% valid). RPKI uses ROAs (Route Origin Authorizations) to authorize which autonomous systems can originate prefixes, helping networks reject invalid route announcements. However, RPKI only validates prefix origination, not route paths or overall routing security.
  • The PKI Consortium released PKI Maturity Model 2.0.0, a vendor-neutral framework for assessing PKI implementations. Key updates include a new Cryptography category covering algorithms, protocols, and crypto agility; expanded certificate validation and inventory requirements including trust anchors; and a free web-based self-assessment tool supporting full requirement-level evaluation.
  • Let's Encrypt will transition from 90-day to 64-day certificate lifetimes by default starting February 10, 2027, with options for 45-day or 6-day certificates. The authorization reuse period will be reduced from 30 days to 10 days immediately, and further to seven hours in 2028. Staging begins October 14, 2026 for testing. Organizations should automate certificate renewal processes and update renewal schedules accordingly.
  • Michael Waterman investigates how Microsoft Edge handles Certificate Revocation List (CRL) caching, demonstrating that HTTP cache headers significantly influence CRL reuse alongside CRL validity fields. Through testing on Edge 155, he shows that Edge maintains its own separate CRL cache and recommends using HTTP revalidation strategies (ETag, 304 responses) with appropriate max-age settings to balance revocation freshness with transfer efficiency.

Security

  • SEC Consult researchers discovered email spoofing vulnerabilities in Apple iCloud that allow attackers to spoof arbitrary iCloud sender addresses. The vulnerabilities exploit header smuggling and parsing discrepancies in iCloud's SMTP workflow, where differences between two parsing stages enable attackers to craft messages with multiple From headers or specially crafted headers that bypass parser checks, resulting in recipients seeing spoofed iCloud addresses as senders.
  • In early October, attackers compromised over 300 Tor exit relays by modifying their exit policies to allow SSH traffic (port 22). This enabled them to intercept SSH connections, capture login credentials, and present malicious host keys to users. The Tor project identified and removed the affected relays by October 5. Researchers documented up to 377 compromised relays across 59 operators. Users who connected via Tor during October 1-5 should treat their SSH passwords as potentially compromised and verify server keys.
  • Chrome has rolled out a new security feature that prompts users for permission before loading HTTP (insecure) connections, aiming to reduce risks from malware, phishing, and eavesdropping. The warning appears once per site and persists for at least two weeks after approval. Exceptions are made for sites that cannot obtain HTTPS certificates, such as intranet hosts and local IP addresses. This proactive approach replaces passive "Not Secure" labels and leverages high HTTPS adoption rates (~95% of Chrome users) to minimize warning fatigue.
  • A class of amplification attacks against HTTP/3 servers exploits QPACK header decoding to cause memory exhaustion. Remote unauthenticated clients can force servers to allocate vastly more memory than the traffic sent, potentially causing out-of-memory crashes or resource exhaustion. Many HTTP/3 implementations lack proper decoded-header limits, allowing small HEADERS frames to expand into hundreds of thousands of header objects. Mitigation requires enforcing cumulative decoded-header budgets during decoding, not just checking compressed frame sizes. Multiple implementations including quic-go, Cloudflare quiche, lsquic, Wireshark, and others have been affected, with some remaining unpatched.

We use Claude to help us create the short news section.

Copyright © 2026 Feisty Duck Ltd

86-90 Paul Street, London EC2A 4NE, United Kingdom
www.feistyduck.com / [email protected]

You are receiving this email because you are subscribed to the Cryptography & Security Newsletter (previously Bulletproof TLS Newsletter). If you'd prefer not to receive further emails, please here.