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. Maintained by Hanno Böck.

Let's Encrypt downtime

It’s been expected for a long time, now it’s finally happened: the research team from Marc Stevens at CWI Amsterdam teamed up with Google to create two files with the same SHA-1 hash. Hash functions like SHA-1 are an important building block of almost all cryptographic protocols. If collisions are found, they are considered broken for most cryptographic use cases.

While this is an important result, it wasn’t unexpected: In 2005 Xiaoyun Wang and her team found major weaknesses in SHA-1. Since then it was clear that breaking SHA-1 was just a matter of resources.

SHA-1 is used in TLS for several purposes. Certificate signatures utilized the hash function in the past, but pressure from browser vendors made certificate authorities switch to the stronger SHA256. However, there are still regular requests for exceptions in order to support old hardware. In response to the collision, Firefox has completely disabled support for SHA-1 signatures in certificates.

Signatures within the TLS handshake also often use SHA-1. TLS 1.1 uses a combination of SHA-1 and MD5. The newer TLS 1.2 allows different hash functions, but still provides an option for SHA-1. The weaknesses of these constructions have been investigated in the SLOTH research published last year.

Short news

• Bugs in Bluecoat devices and other TLS man-in-the-middle proxies hamper the deployment of TLS 1.3. According to a bug report, Chrome developers had to disable support for a draft version of TLS 1.3, because a major Google customer was using TLS interception devices from Bluecoat. This is particularly noteworthy, because the designers of TLS 1.3 took some extra effort to reduce breakage with incompatible, broken devices by introducing the new version negotiation mechanism GREASE. But it seems some breakage can’t be worked around. Just last month researchers warned that TLS interception devices are very often the source of serious vulnerabilities and harm TLS security.
• The major IT security news of the past month was the Cloudbleed incident, discovered by Tavis Ormandy from Google. A bug in a HTML parser on Cloudflare’s servers caused the leakage of memory. While not directly related to TLS, the bug compromised the security of HTTPS connections, because content was leaked from the servers and thus outside of the encrypted channel.
• The German IT news webpage Golem.de now uses HTTPS. (The author of this newsletter regularly writes for Golem.de.)
• The EdDSA elliptic curve signature algorithm is now published as RFC 8032 by the IETF.
• Citrix published an update fixing random nonce generation for the GCM encryption algorithm. This is related to research published by the author of this newsletter last year.
• Filippo Valsorda discovered a bug in the session ticket handling of F5 BIG-IP devices that leaked memory. Given that the bug is similar to Heartbleed, it’s been named Ticketbleed.
• Jean-Philippe Aumasson discovered a bug in mbedTLS that allows forging signatures with RSA-PSS due to an integer overflow. According to Aumasson ARM, the company developing mbedTLS confirmed having received the report, but then didn’t follow up on it.
• The servers of Python’s PyPI system will soon deprecate old TLS versions and only support TLS 1.2. This is due to changes by their provider Fastly, who will change them according to PCI DSS (credit card) standards.
• Ryan Sleevi from Google proposed a change in the CA/Browser forum that would limit the lifetime of certificates to 398 days. This would allow it to deploy changes in the certificate ecosystem faster. However, the proposal wasn't welcomed by most certificate authorities: 24 voted against it, only Let’s Encrypt supported it.
• Browsers usually cache intermediate certificates. This can be used as a fingerprinting mechanism to identify browser users.
• OpenSSL fixed a security vulnerability in the handling of the Encrypt-then-MAC extension. The vulnerability could crash servers and clients and only affects the 1.1.0 versions of OpenSSL.
• Chrome developer Chris Palmer explains changes in Chrome’s user interface for HTTPS certificates in a blog post.
• NCC Group performed an audit of the TLS 1.3 implementation in Go written by Cloudflare.
• Mozilla developer Tim Taubert explains what the changes to session resumption in TLS 1.3 mean for forward secrecy.
• The TLS testing tool SSLyze released version 1.0.0.
• After a lengthy debate Ruby’s secure random number generator now uses the system random number generator if it’s available.
• Glibc 2.25 now supports the getrandom() function, which uses a relatively new system call in the kernel. LWN has a detailed article about it.
• The Caddy web server works on a feature to detect TLS man-in-the-middle devices.
• The Go 1.8 release contains multiple improvements of their TLS stack, including support for X25519 and ChaCha20-Poly1305.
• The CA Security Council has published an endorsement on how they’d like to see web site identify handled.
• A research paper investigates the potential of replay attacks on the zero round trip functionality of TLS 1.3.
• Last June a new record in calculating discrete logarithms in 768 bit was achieved. A group of researchers has now published a paper on the topic..
• The NDSS conference has a session with various presentations about TLS-related topics.