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 major issue with some cloud providers allowed the unauthorized issuance of Let’s Encrypt certificates. Although the issue clearly lies with the cloud providers, Let’s Encrypt nevertheless has decided to disable the corresponding validation method.

Frans Rosén discovered that he could use the SNI validation method from the ACME protocol to issue certificates for domains hosted on certain cloud providers. He explicitly mentions Heroku and Amazon CloudFront.

The core of the issue is that these providers allow users to upload certificates that the system will serve automatically to TLS requests with the corresponding server name. The ACME SNI validation method uses temporary certificates that end with .acme.invalid.

After the issue was reported, Let’s Encrypt almost immediately disabled the TLS-SNI-01 validation method. Let’s Encrypt subsequently decided that, with a few exceptions, it will stay disabled. The newer TLS-SNI-02 method is vulnerable as well. A new TLS-SNI-03 method that considers this problem is being developed, but for the time being users should switch to either the HTTP or the DNS validation method.

Short news

• The author of rustls provided some benchmark data comparing its performance with OpenSSL.
• The CT Observatory provides a web interface for data from Certificate Transparency logs.
• Google now provides a server supporting the draft of the DNS-over-HTTPS protocol.
• Last month, we reported about certificates embedded in software. More cases now have been discovered: Comodo, Intel, and UnionPay all had similar issues.
• The Real World Crypto conference in Zürich included talks about HACL (formally verified crypto in NSS), the TLS standardization process, TLS ecosystem problems with the deployment of TLS 1.3, and more.
• Mozilla announced that all new web features in Firefox will require secure contexts (meaning HTTPS or localhost connections).
• The Trust Store Observatory provides download links for the certificates included in various root stores of browsers and operating systems.
• Some top-level domains have been added to the HSTS preload list: .bank and .insurance. Browsers that use the HSTS preload list will always load domains using these TLDs over HTTPS.
• OpenStreetMap is now using HTTPS by default.
• Scott Helme wrote a blog post with a provocative title: "We need more phishing sites on HTTPS!"
• NSS 3.35 has been released. Changes include support for the latest TLS 1.3 draft and formally verified implementations of ChaCha20 and Poly1305.
• OpenSSL has announced changes in its development structure, particularly regarding mailing lists and the use of GitHub.
• Symantec failed to update one of its HTTPS certificates; visitors to one of its subdomains therefore received a certificate-expiration error message.
• CNN is now using HTTPS by default.
• Chrome removed support for CN fields in certificates because they’ve been deprecated for many years. But it was still possible to re-enable support with an enterprise policy because enterprise devices tend to use outdated technologies and often still used the CN field exclusively. That option will be removed in Chrome 66.
• Wired points out that the data connections from Tinder aren’t fully protected with HTTPS.
• DigiCert announced that it will start logging all certificates to Certificate Transparency starting February 1 and will add SCTs to them. Chrome will require CT logging and SCTs for new certificates in April.
• A paper discusses the impact of post-quantum signatures for X.509 certificates.
• A web page titled "Why does APT not use HTTPS?" argues that the Debian package manager is not using HTTPS mainly because APT always verifies signatures.
• The latest Java update includes some TLS updates, including support for TLS session hash, the extended master secret extension, and negotiated finite field Diffie-Hellman parameters.
• A discussion in the CA/Browser Forum has erupted about which versions of the Baseline Requirements and the forum’s bylaws are currently valid.
• TLS 1.3 is in last call, meaning that we could see a final TLS 1.3 RFC soon. However, this isn’t the first last call we’ve seen for TLS 1.3. The reason it’s taking so long is not due to the standard itself, but due to ecosystem issues (see the earlier link to David Benjamin’s talk at Real World Crypto for details).
• Microsoft announced that it will require TLS 1.2 for Office 365 in March. Support for TLS 1.0 and 1.1 will be disabled.
• DigiCert has raised some issues with questionable domain validation methods that don’t include any technical check of domain ownership. This has led to a longer discussion about deprecating such validation methods, but particularly Entrust opposed this and wanted to keep the problematic validation method or a very long transition time.