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.

A seemingly minor issue is the cause of major trouble in the certificate industry: many certificate authorities have used serial numbers with sixty-three bits of entropy for their certificates, yet the Baseline Requirements say that they need sixty-four bits.

Originally this issue was discovered in certificates from the DarkMatter certificate authority based in the United Arab Emirates. As we reported last month, DarkMatter is controversial due to a report released by Reuters. Adam Caudrill was the first to make the issue public to a wider audience via a blog post.

The issue itself is subtle. The Baseline Requirements say that certificate serial numbers need to have sixty-four bits of entropy. The affected certificates use sixty-four-bit integer numbers, but an integer number can be negative, and the Baseline Requirements also say that certificate serial numbers need to be positive. This means that negative numbers are discarded, so effectively these certificates have a random sixty-three-bit serial number.

It turned out that this behavior was the default in EJBCA, free software for certificate authorities. Many certificate authorities use EJBCA, and thus a large number of certificates are affected by the same issue. In the past weeks, more and more certificate authorities came forward and sent reports to Mozilla’s security policy mailing list about this issue.

From a security perspective, the issue is almost meaningless. The entropy requirement was introduced due to attacks that became possible with the use of weak hash functions. A collision attack in MD5 allowed researchers to forge a certificate, as explained in a talk the researchers gave at the Chaos Communication Congress in 2008. This attack relied on the fact that the targeted certificate authority used sequential serial numbers for certificates, which meant the researchers were able to guess the most likely serial number for a certificate.

Such attacks are only possible with hash functions that are cryptographically broken and don’t provide collision resistance. Given that the weak hash functions MD5 and SHA1 are already deprecated in the certificate ecosystem, there’s little concern. The entropy requirement is still a useful defense-in-depth mechanism in case the modern hash function SHA256 turns out to have similar weaknesses in the future, but it seems unlikely to matter in practice. Even if there was a similar weakness, sixty-three bits are still enough to make such an attack almost certainly impossible.

But the Baseline Requirements have mechanisms that say that certificates violating the rules must be revoked, whether or not there’s a practical security risk. Many people in the TLS community are unwilling to endorse a lax handling of existing rules because doing so may create a bad precedent for other, more serious violations.

The Baseline Requirements demand a revocation of certificates violating the rules within five days of discovery. This window has already passed for many of the affected certificate authorities. It will be a challenge for them to inform their customers and replace all the affected certificates.

Short news

• F5 has published a security update for a padding oracle vulnerability in its products.
• DigiCert mistakenly issued a certificate for an in-addr.arpa domain and a localhost address.
• A recent research paper proposes a new way to allow forward secrecy together with zero-round-trip session resumption in TLS.
• Adi Shamir, one of the inventors of the RSA algorithm, was denied a US visa for the annual RSA conference.
• OpenSSL published information about a low-severity vulnerability with long nonces in the Chacha20-Poly1305 encryption mode.
• A blog post reports about the use of Let’s Encrypt certificates for internal host names.
• The ACME protocol for automated certificate issuance is now standardized as RFC 8555. The standardized version is the second version of the ACME protocol, and Let’s Encrypt announced plans to slowly deprecate the old ACME v1 protocol.
• Cloudflare published tools to analyze TLS interception by middleboxes and presents its own results on the prevalence of TLS interception in a detailed blog post.
• Researchers have analyzed the security of AES against quantum attacks. They conclude that “AES seems a resistant primitive in the post-quantum world as well as in the classical one.”
• In the Go crypto library, a security vulnerability in the Salsa20 algorithm that happens when more than 256 gigabytes of data is encrypted was fixed. This vulnerability causes a counter overflow.
• Will Dormann from CERT/CC reports that the group found a large number of private keys in Android apps, some of them connected to publicly trusted certificates. Certificates with known compromised keys must be revoked according to the Baseline Requirements.
• Leo Perrin, a researcher at Inria, explained his concerns about the design of the S-boxes of the Russian Streebog and Kuznyechik ciphers.
• The developers of TLS-Attacker explain the use of the tool and some recently added features in a blog post.
• Researchers of the University of Hamburg investigate the possibility of speeding up QUIC by sharing address validation among different hosts.