Cryptography & Security Newsletter

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.

During a recent meeting of the CA/Browser Forum, Apple announced that its Mac OS and iOS operating systems will not accept certificates with a lifetime of more than 398 days starting in September of this year. With this announcement, Apple moves ahead with the shorter certificate lifetimes that multiple browsers have wanted for a while.

There are a number of advantages to shorter certificate lifetimes. One notable one is that implementing new features and deprecating old ones can happen much faster than in the past. The phaseout of SHA1 signatures is often cited. Another example is certificate transparency: although Google’s Chrome browser has required support for certificate transparency SCTs in new certificates since April 2018, it will take until June 2021 before the last certificates created prior to that will expire.

The other major reason for shorter certificate lifetimes is the lack of a working revocation mechanism for compromised certificates. Certificate revocation has been problematic for a long time. Revocation checks via OCSP have usually only been implemented in a soft-fail mode that does little in an attack situation in which an attacker can simply block connections to the OCSP server. Although mechanisms that can provide better revocation than this exist—OCSP stapling and the Must-Staple certificate extension—they have not been deployed widely.

Thus the rationale for shorter certificate lifetimes: in the event of a compromised private key, a shorter remaining lifetime will reduce the time an attacker has to cause harm.

Certificate lifetimes have been gradually reduced over time. More than a decade ago, certificates sometimes were valid for more than ten years. In 2017, the CA/Browser Forum agreed to cap certificate lifetimes at 825 days. However, multiple attempts to agree to further shorten certificate lifetimes have failed in the CA/Browser Forum.

Certificate authorities cite issues that their customers have with shorter certificate lifetimes. If certificates are changed manually, then this is obviously an issue, but many people think that certificate automation is the way forward.

Certificate automation has been made popular by Let’s Encrypt, and with ACME there is a standard to allow automatic issuing of certificates. But not all certificate authorities provide automation yet—and even if they did, not all products using certificates support ACME.

Despite these concerns, it seems browsers have decided to move on with shorter certificate lifetimes without the support of the majority of certificate authorities. Apple is the first company to announce such a move, but it is expected that other browsers will follow as all of the browser vendors in the CA/Browser Forum have previously announced that they want shorter certificate lifetimes.

If you’re interested in a more detailed history of this discussion, Scott Helme has followed the debate in his blog over time in much more detail.

Short News

• An RFC for the GREASE mechanism has been published. GREASE is a method to make sure TLS implementations stay flexible for future changes.
• Chrome announced plans to warn about and later block insecure download links from HTTPS pages.
• In a blog post, Saleem Rashid explains how service workers could be used to abuse the recently disclosed private key disclosure from Netgear routers.
• On February 3, several Microsoft services, including the Teams chat service, were unavailable due to an expired certificate.
• The Washington Post published a detailed background story about the swiss company Crypto AG, which for several years sold backdoored encryption hardware and was operated by the CIA and the German BND.
• Aaron Peters blogs about EV certificates and how a browser’s OCSP checking of these certificates can cause a slowdown.
• OpenSSL developers published a blog post discussing QUIC and a possible future API for it. The OpenSSL developers believe that QUIC is not stable enough to already get a stable API and therefore will likely not be provided in the upcoming version 3.0.0.
• A discussion has been started about adding more algorithms, including X25519 but possibly also Chacha20/Poly1305 and others, to the WebCrypto API.
• Let’s Encrypt started enabling multiperspective validation, meaning that domain validation will be checked from multiple, internationally distributed points of the internet. Multiperspective validation has been developed as a defense against BGP hijacking and other network layer attacks against domain validation.
• A paper published via the Cryptology ePrint Archive looks at the impact of postquantum signatures on TLS.
• With the upcoming Linux Kernel 5.6, there will be some major changes in the handling of the random number generator. Most notably, /dev/random will no longer block. Filippo Valsorda describes the details in a blog post.
• The Zlint tool version 2.0.0 has been released and includes major refactoring. Zlint is a linter for X.509 certificates.
• Chrome plans to support 3DES and SHA1 in handshake signatures only via a fallback connection.
• Mozilla Firefox changed the minimum DTLS version for WebRTC to DTLS 1.2; in Chrome, deprecating old DTLS versions is still discussed.
• Last year, Mozilla decided to reject a request by the DarkMatter company for inclusion of its root certificate, due to the company’s involvement in spying activity for the United Arab Emirates. DarkMatter appealed to the Firefox Technical Leadership in Mozilla, which has now confirmed the decision to reject DarkMatter’s inclusion request.