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.

The four largest browser vendors—Google, Microsoft, Mozilla, and Apple—have all announced that in 2020 they want to deprecate old TLS protocol versions 1.0 and 1.1. Webmasters should make sure that they support at least TLS 1.2, or ideally the latest version, TLS 1.3.

Although TLS 1.0 and 1.1 do have some security issues, it’s debatable how severe they are. TLS 1.0 is vulnerable to the BEAST attack, but that can be mitigated relatively easily by clients. Both TLS 1.0 and 1.1 use insecure hash functions like MD5 and SHA1, a detail that has been explored in the SLOTH attack.

Browser vendors still have not moved to deprecate weak cipher modes that are still supported in TLS 1.2—notably, CBC/HMAC with MAC-then-encrypt and the static RSA handshake. However, Google’s announcement indicates that further deprecations will follow and recommends supporting AEAD modes and the ECDHE key exchange.

It’s noteworthy that four major browser vendors have coordinated their efforts to deprecate old encryption protocols. This is likely due to past discussions in which such deprecations were met with resistance because when one browser vendor moves ahead, it could make users switch to another browser. Although their timelines aren’t fully aligned, the coordinated deprecation will make such scenarios less worrying for the vendors.

Short news

• With version 70, the Chrome browser started distrusting Symantec certificates. The feature was rolled out incrementally and doesn’t affect all users yet. Meanwhile, Mozilla has delayed the Symantec distrust for a bit and Microsoft announced timelines that are much longer than those of other browser vendors.
• People regularly forget to renew their HTTPS certificates. Last month this happened to the German information security authority (BSI) and to Comodo’s certificate search engine, crt.sh.
• Let’s Encrypt announced that it will end support for the TLS-SNI-01 validation method in February 2019. This method has a major security flaw in combination with the behavior of some cloud-hosting services, which was discovered in January by Frans Rosén. For compatibility reasons, Let’s Encrypt still continued to allow this validation method in some cases.
• Michael Driscoll created a web page explaining the TLS handshake in detail.
• TLS 1.3 has been plagued by many deployment issues due to faulty implementations of old TLS protocol versions. The protocol itself tries to work around many of those issues, but some still persist, as Chrome developer David Benjamin pointed out in the TLS working group list. Cisco has published updates that affected users should install as soon as possible. Prereleases of OpenSSL 1.1.1 cause compatibility issues, so users of those prereleases should switch to the final version. Devices from Palo Alto Networks also have issues, but no update has been provided for them yet.
• A cloud provider had connection failures with HTTP/2 in combination with TLS 1.3, according to a Mozilla bug report. The reason was that they didn’t accept the TLS 1.3 ciphers as safe. This affected some Twitter users.
• Mozilla announced support for Encrypted SNI (ESNI) in their Firefox Nightly builds.
• DNS over HTTPS has been published by the IETF as RFC 8484.
• A security vulnerability has been found in the certificate-checking function of the Ruby OpenSSL module.
• A state machine error led to a severe vulnerability in the server part of the LibSSH library.
• NSS has released version 3.40. Changes include a fix for FFDHE and the removal of the Visa certificate authority.