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 Rust programming language is gaining more popularity, and it increasingly affects cryptographic code as well. Rust’s main selling point is that the language provides many memory safety guarantees, making bugs like buffer overflows and use after free errors much less likely to happen (they can still happen in code specifically marked as “unsafe”).

Daniel Stenberg, the main developer of the curl HTTP library, recently announced support for a new curl TLS backend using rustls. Rustls itself is, as the name implies, a TLS library written in Rust. Curl is also working on adding a new backend based on Hyper, an HTTP library written in Rust.

Also recently, the ISRG (Internet Security Research Group) announced that it will support a Rust-based TLS module for the Apache web server, with funding coming from Google. This is part of a larger effort by Google and the Open Source Security Foundation to fund ports of critical pieces of open-source software into memory-safe languages.

Another project’s move to Rust, the cryptography package for Python, recently led to some hefty discussions as it means that some older platforms that lack a Rust compiler will no longer be supported. The cryptography project started reimplementing parts of its ASN1 parsing code in Rust. ASN1 parsers have often been affected by memory-safety vulnerabilities in the past.

With Rust getting more popular, this will also lead to more cryptographic and TLS code getting rewrites in Rust. Given that one of the most well-known TLS vulnerabilities of all time, the OpenSSL Heartbleed bug, was a memory-safety violation, this is not a surprising development.

Short news

• Version 1.9.0 of libgcrypt was vulnerable to a heap overflow in the handling of hash blocks. This problem is fixed in version 1.9.1. The bug was discovered by Tavis Ormandy from Google’s Project Zero.
• A new version of the freely available OpenSSL Cookbook was published by Feisty Duck. (Feisty Duck is also the publisher of this newsletter.)
• Mozilla will no longer trust Camerfirma’s certificates for HTTPS connections. As we reported last month, Google Chrome had already announced a similar decision earlier.
• A company called Terra Quantum made some headlines with statements about breakthroughs in quantum attacks and with claims about post-quantum cryptography being broken. Although the company provided no evidence for those claims and it was hard to even understand what exactly it was claiming (it made references to inverting MD5 and breaking AES), it was reported on by Bloomberg. Soatok discusses this in a blog post and gives a good summary.
• OpenSSL published a security advisory and corresponding updates. This includes a null pointer bug in an X509 parsing function, an integer overflow, and a potential weakness in SSLv2 downgrade protection that only affects older OpenSSL branches. Fixes are in OpenSSL 1.1.1j.
• A research paper published on Arxiv looks at revocation practices in X509 certificates.
• APNIC provided a detailed analysis of the HTTPS interception that was happening in Kazakhstan in 2019. (We covered the Kazakhstan HTTPS interception in our July 2019 newsletter.)
• OpenSSL published alpha 12 of the upcoming version 3.0.0.
• NSS released version 3.62. Most of the changes are related to ECH (Encrypted ClientHello).