Home Books Training Newsletter Resources
Sign up Log in

Cryptography & Security Newsletter

66

Expired AddTrust certificate causes trouble

30 Jun 2020

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 Hanno Böck.

The expiration of an old root certificate by Sectigo was the cause of some trouble on May 30. The AddTrust certificate was used to cross-sign the newer USERTrust certificate, and in some situations the expired cross-signature certificate caused verification failures. Andrew Ayer has written a blog post with a detailed technical explanation.

A client that implements certificate verification and path building correctly should not have any issues with such an expired root certificate. It should detect that it could also validate the certificate against the newer USERTrust certificate and ignore the expired AddTrust intermediate and root. Browsers were largely unaffected by this issue. Most issues happened with tools either using GnuTLS or older versions of OpenSSL.

The issue could be mitigated in various ways. Although the fault lies with the client library, administrators could mitigate this issue by no longer serving the expired AddTrust intermediate certificate in the chain. Removing the old AddTrust certificate from the chain is also recommended for performance reasons. Shortly after the incident, GnuTLS released an updated version that fixed certificate validation in such instances, and the patch was also backported into most Linux distributions.

In the aftermath of the AddTrust incident, Google developer Ryan Sleevi wrote two blog posts detailing certificate validation issues in TLS libraries. In the first post, Sleevi describes how certificate path validation should ideally be done, and in the second post the validation code of several popular TLS libraries is analyzed. To better analyze certificate paths, Rob Stradling has implemented the possibility to display certificate path graphs in the crt.sh certificate search engine.

Subscribe to the Cryptography & Security Newsletter

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

Short News

  • Google’s David Benjamin describes some observations and problems with TCP and TLS 1.3 API interactions.
  • LibreSSL 3.2.0 was released and enables TLS 1.3 on the server side by default.
  • GnuTLS fixed a severe security flaw in the handling of session tickets. In TLS 1.2 and earlier, the flaw allows passive decryption of TLS traffic. In TLS 1.3, it is vulnerable to active man-in-the-middle attacks.
  • Felix Wilhelm from Google’s Project Zero found a flaw in the Node.js TLS code that allows a hostname verification bypass. Node.js released a security update.
  • OpenSSL released alpha 3 and alpha 4 of version 3.0.0.
  • The company Cure53 performed a security audit of the ring, rustls, and webpki Rust TLS and crypto libraries.
  • A vulnerability in handling the IMAP PREAUTH command allowed an attacker to prevent an encrypted STARTTLS connection in Thunderbird. A similar bug was also found and fixed in the Alpine email client.
  • The Trojitá mail client failed to check the certificates of SMTP TLS connections.
  • Let’s Encrypt has asked for input on the plan for its new intermediate certificate hierarchy.
  • Let’s Encrypt originally planned to transition to a new intermediate and root certificate starting this July, but the date has been postponed to September.
  • Heroku had changed the certificate provider for the wildcard certificate of its hosted apps from DigiCert to Starfield/AWS. However, some users had created applications that were pinned to the old certificate issuer, thus causing failures. Now Heroku has switched back to a certificate issued by DigiCert, but also said that it doesn’t guarantee any specific certificate provider and that it recommends against pinning to a specific issuer.
  • Andrew Ayer reviewed the CFSSL signer code that is used by some certificate authorities and highlights some potential issues.
  • Leo Dorrendorf of the VDOO company discusses a security issue in the BusyBox-integrated wget command in a blog post. The command does not validate TLS certificates, and the BusyBox maintainers do not plan to change this due to potential compatibility issues. VDOO provides a patch and instructions on how to fix this.
  • The US government’s DotDev project announced plans to add the complete .gov top-level domain to the HSTS preload list. No specific timeline was announced, but starting September 1, new subdomains at least will always be added to the preload list.
  • A research paper discusses the security tightness of TLS 1.3 security proofs.

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