Bulletproof TLS Newsletter

Bulletproof TLS Newsletter is a free periodic newsletter bringing you commentary and news surrounding SSL/TLS and Internet PKI, designed to keep you informed about the latest developments in this space. Received monthly by more than 50,000 subscribers. Written by Hanno Böck.

The Let’s Encrypt certificate authority is facing a challenging situation with its upcoming planned certificate switch.

Let’s Encrypt originally started with an intermediate certificate that was cross-signed by a root certificate owned by the IdenTrust certificate authority, but this root certificate, called DST Root CA X3, will expire in September 2021.

Let’s Encrypt has its own root certificate (called ISRG Root X1) and can issue its own intermediates. But given that the ISRG root certificate is newer, it isn’t as widely preinstalled on devices and operating systems. In particular, older Android versions—which are in widespread use—do not have it preinstalled.

To circumvent these problems, Let’s Encrypt now intends to get a new cross-signed intermediate from IdenTrust’s expiring root certificate. This is unusual, as the new intermediate would be valid longer than the root certificate issuing it. However, this still guarantees compatibility because in Android the certificate validation is implemented in a way that doesn’t check the expiration date of the preinstalled root certificates.

The new intermediate will not directly sign end-entity certificates. Instead, it will indirectly sign the current Let’s Encrypt intermediate certificate, R3. This ensures that clients that know the Let’s Encrypt ISRG root certificate and that check the expiration dates of root certificates will still accept the certificate chain. The downside of this approach is that the chain will contain two certificates, creating additional traffic overhead.

Let’s Encrypt plans to offer alternative certificate chains so that clients can choose between a smaller chain and the longer chain that provides compatibility with older Android devices.

Short news

• A research paper published on arXiv analyzes TLS interception mechanisms.
• OpenSSL published alpha 9 of the upcoming version 3.0.0.
• TLS Certificate Compression was published by the IETF as RFC 8879.
• Let’s Encrypt’s new R3 intermediate certificate may cause some issues for people using DANE for certificate pinning, as explained on the Exim mailing list.
• A discussion about the Camerfirma certificate authority was started on Mozilla’s security policy mailing list. A list in the Mozilla Wiki gives an overview of a variety of policy violations and security problems with this certificate authority.
• Internet providers in Kazakhstan have started asking users to install a root certificate allowing traffic interception, similar to previous events that we covered in our newsletter in July 2019. Various browser vendors have announced that they will block this root certificate.
• The latest curl release, 7.74.0, supports HTTP Strict Transport Security (HSTS). The curl developer, Daniel Stenberg, explained the feature in a blog post.
• OpenSSL fixed a null pointer dereference bug in a certificate handling function. In some situations, like checking certificates against CRL lists, this could allow an attacker to crash applications using OpenSSL. The same bug affected and was fixed in LibreSSL.
• Curl fixed a security vulnerability that in some situations allowed bypassing OCSP checks with OCSP stapling. The vulnerability was reported via HackerOne.
• GnuTLS published version 3.7.0, which adds a number of new API functions.
• DigiCert provides a webpage and an API that allows automated certificate revocation in case of a key compromise.
• A research paper published on the Cryptology ePrint Archive and planned for the upcoming USENIX Security 2021 conference introduces an attack called Partitioning Oracle against AEAD ciphers. In some situations, this attack allows the attacker to figure out if a ciphertext belongs to a known subset of keys.