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.

Starting April 30, the Chrome browser will require all new certificates to be compliant with Certificate Transparency. This is a major change in the certificate ecosystem and was prepared over several years. Certificate Transparency has already played a major role in many cases of uncovering mistakes by certificate authorities.

The core idea of Certificate Transparency is relatively simple: All publicly issued certificates are stored in public append-only logs. These allow everyone to check whether illegitimate certificates for their domains have been issued. To show that a certificate has been logged, two so-called signed certificate timestamps (SCTs) have to be provided during the TLS handshake. An SCT is a signed statement from a log confirming that a certificate has been submitted.

There are different ways to deliver an SCT, but the most common one is to add it directly to the certificate itself. Most certificate authorities do this automatically, so there is nothing a site operator has to do manually. Because a CA can’t log a certificate before it’s been issued, these certificate-embedded SCTs require issuing a precertificate, which contains a special extension and is identical to the final certificate, except that it lacks the SCTs.

This raises the question of whether both the precertificate and the final certificate should be logged or just the precertificate. Let’s Encrypt initially decided to log only the precertificate when it introduced SCTs, but it’s now working on logging the final certificate as well.

Although Certificate Transparency logging is now a requirement for new certificates, a rogue or compromised CA still may be able to create unlogged certificates by backdating them. This can be prevented by using the Expect-CT header.

The Hardenize service has added a check for Certificate Transparency compliance.

Short news

• Like other browsers, Safari also now warns users when they use forms on unprotected HTTP pages.
• CurveSwap is a theoretical attack scenario that could arise because parts of the TLS handshake are unauthenticated. A research paper uses this as a starting point to investigate the use of elliptic curve cryptography in the wild.
• Cloudflare announced its Certificate Transparency log, Nimbus.
• Tinydoh is a Go implementation of DNS over HTTPS.
• More companies and projects have announced the deprecation of old TLS versions 1.0 and 1.1: certificate authority DigiCert, the KeyCDN company, and Python package repository PyPI.
• Starting in April, Chrome requires SCTs from Certificate Transparency logs for all new certificates. Let’s Encrypt has started automatically embedding them into all new certificates.
• Mike West wrote a proposal to limit the validity times of cookies sent over insecure HTTP connections.
• Vodafone Portugal rewrites Content Security Policy headers of HTTP requests. ISPs manipulating HTTP content is considered an important reason for even static pages with no secret content to deploy HTTPS.
• The Kudelski Security company explained Manger’s attack against RSA OAEP.
• Adam Langley wrote about a test that Cloudflare and Google performed to determine the feasibility of post-quantum key exchanges in TLS 1.3. Post-quantum algorithms usually come with larger key sizes; the experiment simulated this by adding dummy extensions to the TLS handshake. Independent of that test, researchers from Cisco have set up an experimental post-quantum PKI using X.509 extensions to add post-quantum capabilities to certificates.
• Franziskus Kiefer from Mozilla wrote about Mozilla’s efforts to use formally verified cryptography from the HACL project.
• OpenSSL released an advisory about a timing issue in RSA key generation. A corresponding research paper has been published at the Cryptology ePrint Archive.
• A research paper investigates replacing the cryptographic algorithms implemented in OpenSSL dynamically with other implementations, which in some cases leads to significant speedups.
• The forum provider Discourse blogged about its support for HTTPS by default.
• Ian Carroll has now for the second time requested an Extended Validation certificate for one of his subdomains in the name of “Stripe, Inc.” He has registered a company under that name, which is not the well-known payment provider Stripe. The point of this is to show that Extended Validation certificates have little value. The certificate authority GoDaddy has revoked that certificate, which in turn has led to debates whether the revocation was legitimate. Scott Helme has covered the debate in a blog post.
• A research paper investigates security problems with Java keystores.
• The certificate for the domain hosting the official jQuery library expired. This led to a large number of websites breaking because it’s common practice to include jQuery from the upstream host and not host it locally.
• The testssl.sh tool has released version 3.0 beta, including support for TLS 1.3, detection for the ROBOT vulnerability, and support for OpenSSL 1.1.
• A flaw in the RSA key generation algorithm of Bouncy Castle could lead to a too-low number of primality tests. With a very low likelihood, this could lead to weak keys being generated.
• BGP hijacking was used to attack the visitors of MyEtherWallet, an Ethereum site. This led to some discussions about the risk of BGP vulnerabilities being used to forge certificate issuances—although in this case no such certificate forging happened. A blog post at Cloudflare explains the details. This attack scenario isn’t new; it was discussed in a 2015 Black Hat talk and in research papers.