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.

A large number of certificates are affected by an issue in which intermediate certificates can also act as OCSP responder certificates.

This issue was highlighted by Google developer Ryan Sleevi in early July. Sleevi found over 200 certificates that were issued by publicly trusted certificate authorities with an extended key usage flag that allows them to act as OCSP responder certificates. However, these certificates were missing an extension (id-pkix-ocsp-nocheck) that is required for such certificates, so they are in violation of the Baseline Requirements.

Many of these certificates were not intended as OCSP responder certificates; they were really intermediate certificates used to issue normal web page certificates. The reason these certificates have been created seems to be due to some behavior of Microsoft’s CA software, which was discussed in an email thread in 2019.

Usually certificates that violate the Baseline Requirements should be revoked within seven days. But Ryan Sleevi argues that revoking may not be sufficient in this case. Because these certificates can sign OCSP responses, they could be used to sign valid OCSP responses for themselves. Sleevi therefore argues that CAs should destroy the private keys corresponding to these certificates and provide a report documenting the key destruction.

Another problem in this case is that a large number of web page certificates rely on these intermediates and it is unclear when they will all be revoked. Nevertheless, web page operators of affected sites should ask their certificate authorities for replacement certificates and replace them as soon as possible.

Various tools are available to help website operators check if they are affected. The Hardenize service shows a warning for affected certificates. The TLS Certificate Health Checker from Oh Dear can also be used to check for this issue. And a simple shell script to check hosts is provided by the author of this newsletter.

Short News

• NSS released version 3.55, including various smaller security fixes. Some flaws in algorithm implementations were found with the Cryptofuzz tool.
• OpenSSL published alpha 5 of the upcoming version 3.0.
• Johannes Weber performed an analysis of a hostname’s DNS and HTTP requests after registering a certificate for a previously unknown hostname. Due to Certificate Transparency, hostnames in certificates are publicly revealed.
• Emily Stark from Google Chrome’s security team explains Certificate Transparency in a blog post.
• In the context of the Black Lives Matter protests, many software projects engaged in discussions about the use of IT terminology that can be perceived as racist. Rich Salz proposed various changes to OpenSSL, but the pull request was rejected by a vote of the OpenSSL Management Committee. Rich Salz announced that he will leave the project as a result. A smaller pull request that changes some wording and avoids public APIs was later merged.
• A research paper published at USENIX investigates cryptographic security issues with Estonian ID cards.
• Debian recently removed the distrusted Symantec root certificates from its ca-certificate package. However, that led to unexpected problems because some intermediates signed by those roots are still in use. Browsers have a more complex certificate validation logic that in some cases isn’t easily representable by the more simple certificate validation that smaller tools perform with the help of the ca-certificates package.
• DigiCert has revoked a large number of certificates due to a missing audit.