Home Books Training Newsletter Resources
Sign up Log in

Cryptography & Security Newsletter

118

Apple Wants to Limit Certificates to Forty-Five Days

31 October 2024

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

Are we ready for forty-five-day certificates? Apple seems to think so. On October 10, 2024, CA/B Forum ballot SC-81 appeared as pull request #553 in the Server Certificate Working Group’s repository. Just like that, without a warning.

Before Apple’s pull request, Google was on record for wanting ninety-day certificates at some point, which is why Apple’s proposed forty-five days (by September 2027, over three yearly milestones) came as a shock. But this very small number is not in itself scary: if you’re going to focus on automation, doing things more frequently is the best way to ensure the automation is smoothly implemented. In this case, with certificate lifetime limited to forty-five days, the idea is to get new certificates monthly, leaving about fifteen days for dealing with problems.

But the real questions are: “Why?” and “Are we ready for it?” The why part is possibly easy to explain. In essence, the reduction of certificate lifetimes became inevitable when browsers stopped checking certificates for revocation. Although we often hear that “revocation is broken” and that “revocation is not reliable,” that’s not accurate; browsers decided to drop revocation, and that’s that.

This created a big security hole for anyone who loses control over their private keys—for example, via a security intrusion. It’s technically possible to evolve certificates that opt into revocation (the so-called must-staple indication), but that’s also not a feature the browsers want to support.

The problem with this answer to “Why?” is that it’s difficult for the affected IT workers to accept. Their life is difficult for reasons that have never been fully explained and communicated to the public. Having some answers would make the conversation easier.

To be clear, there is a very good argument to avoid certificate lifetimes that are too long: doing otherwise would limit the ecosystem’s ability to deprecate weak cryptographic primitives. The SHA1 transition took longer than we wanted. However, going below one year breaks an important psychological boundary and increases manual issuance workloads manifold. Is one year too long? Why?

As for “Are we ready for it?” Well, the truth is that nobody really knows for sure. Looking around, we see that there still are CAs who don’t support automated issuance, as well as many systems that can’t use automation. Even leading web server software such as Nginx and Microsoft’s Internet Information Server do not support ACME natively. Not to mention that there are various hardware appliances and IoT systems that don’t have support and which operate on very long replacement cycles that take years.

So, what’s next? SC-81 is not yet an official ballot. It’s been discussed only briefly so far, with the next discussion planned for October 31. We’ll find out what happens next then. Last time, Apple forced the reduction of certificate lifetimes to 398 days, but the world was ready and most people believed that more than a year is too long anyway. This time, the situation is not as clear.

Subscribe to the Cryptography & Security Newsletter

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

Short News

Here are some things that caught our attention since the previous newsletter:

  • Apple is inviting security researchers to break their private cloud computing technology and will pay up to one million dollars for critical flaws. They’re also open sourcing some of the key components.
  • A cyberattack tied to the Chinese government potentially penetrated the infrastructure used for authorized network wiretapping in the US.
  • Google said that the percentage of memory safety vulnerabilities in Android dropped from 76 percent to 24 percent over six years as development shifted to memory-safe languages. Android's Jeff Vander Stoep talked about this on the Security Cryptography Whatever podcast.
  • On the same podcast, an anonymous guest, who has worked on cybersecurity for political campaigns in the United States since 2004, talks about their experiences.
  • The Transparency.dev 2024 Summit was held in London in October; for a quick overview, read Tracy Miranda’s summary. If you have more time, head to the videos.
  • WeChat uses a modified version of the TLS 1.3 protocol; the researchers haven’t been able to break it, but they’re not happy with the changes.
  • crypto-condor is a Python library for compliance testing of implementations of cryptographic primitives (see the introductory blog post from Quarkslab).
  • If you’re catching up with the quantum apocalypse, Pascal Schärli has a gentle introduction.
  • In a 2018 talk, Ricky Mondello from Apple talked about how iOS encourages healthy password practices.
  • In the EU, there is a proposal to use ACME for issuance of QWAC certificates.
  • CT enforcement is now in Firefox Nightly.
  • Read about how compilers break constant-time code.
  • Erik Hjelmvik discusses various options to decrypt TLS traffic on the APNIC blog.
  • AWS Cryptography (via Amazon Research Awards) has put out a call for proposals for funding in the area of cryptographic research.
  • Have you seen the Kazakhstan internet censorship report? The government-mandated root key has been used to intercept “at least 14 distinct domain names on at least 19 different networks in Kazakhstan.”
  • New RFCs are being written to remove SHA1 and GOST from DNSSEC.
  • AWS and Cloudflare have enabled X25519MLKEM768.
  • Germany’s Federal Office for Information Security released a report on the status of quantum computer cryptanalysis. Page 61 shows the estimated quantum computer capabilities to break EC and RSA.
  • In Interval Key-Encapsulation Mechanism, the authors study post-compromise security.
  • Computer scientist Scott Aaronson discusses his feeling that the race to build a practical quantum computer is now genuinely under way in Quantum Computing: Between Hope and Hype.
  • Sam Jaques talks about quantum attacks on AES (slides). Grover’s algorithm may not be as practical as previously thought, leading Sam to conclude that “AES-128 is probably safe from classical and quantum attacks in our lifetimes.”
  • Joe Birr-Pixton created a new Rust project called Graviola, with the aim to provide fast and easy cryptographic primitives.
  • Bitdefender, which is supposed to improve user security, is actually found to have broken certificate validation. (This happens all the time with antivirus software.)
  • Filipo Valsorda talks about the FIPS compliance of HKDF.
  • NIST is updating its password guidance; read about it in a blog post from 1Password. There are some great changes, including telling websites to stop pestering us with special characters.
  • The Irish Data Protection Commission fined Meta Ireland 91 million euros for the 2019 incident when it was discovered that Facebook had recorded millions of passwords as plaintext.
  • Cloudflare has started verifying WhatsApp’s Key Transparency proofs.
  • Michael Waidner explores the state of RPKI on the APNIC blog.
  • In their research paper, Tehrani et al. investigated the intersection of CAA, CT, and DNSSEC worldwide.
  • Marten Seemann writes about a P2P vision for QUIC.
  • German law enforcement agencies are compromising the Tor network.
  • Keyfactor discusses the transition to FIPS 140-3, in the context of HSMs.
  • Vodafone Netherlands has been fined for not properly securing the tapping infrastructure.
  • Bouncy Hsm is a developer-friendly implementation of a cryptographic store accessible through a PKCS#11 interface.
  • Apple’s iMessage PQ3 Protocol has been formally verified.
  • Cloudflare is restarting the rollout of Encrypted Client Hello.
  • certmitm is a tool for testing for certificate validation vulnerabilities of TLS connections made by a client device or an application.
  • In 1974, the NSA launched Cryptolog, a periodical intended as a vehicle for the exchange of technical ideas in its operations. All 136 issues were declassified in 2012, with further information added over time. There are now thousands of items in the archive.

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.

Find out More

@feistyduck

Books

  • Bulletproof TLS and PKI
  • ModSecurity Handbook
  • OpenSSL Cookbook

Training

  • Practical TLS and PKI

Resources

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

Company

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