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 paper published at the USENIX security conference showed a large number of vulnerabilities in STARTTLS implementations. The author of this newsletter participated in this research.

STARTTLS is a mechanism that allows upgrading plaintext protocol connections to TLS. The research focused on STARTTLS in the communication between email clients and servers (SMTP, IMAP, POP3). It turns out this upgrading mechanism is fragile and can lead to a number of security problems.

In 2011, Postfix developer Wietse Venema discovered that when sending additional content together with the STARTTLS-initiating command in the same TCP packet, many servers would interpret this as part of the encrypted connection even though it was plaintext and could thus be injected by a man-in-the-middle attacker.

What we found is that this vulnerability was still quite prevalent and affected many servers. Our research also described how to exploit this vulnerability practically to steal login credentials via a vulnerable SMTP or IMAP server.

We also discovered that a very similar vulnerability exists on many email clients, including popular clients like Mozilla Thunderbird and Apple Mail. While less severe than the server-side vulnerability, this flaw allows forging mailbox content.

An incompatibility between an IMAP feature and STARTTLS also poses a security risk. An IMAP server can signal to a client directly after the initial connection that it is already authenticated and does not need to send credentials via the PREAUTH answer. But in an authenticated state, it is not allowed to send a STARTTLS command. By sending a PREAUTH answer, a man-in-the-middle attacker can thus prevent a connection upgrade from happening.

This PREAUTH vulnerability was originally found in 2014 in a mail client called Trojitá, but we learned that it affected many popular mail clients, including Apple Mail and Mozilla Thunderbird.

These vulnerabilities illustrate that implementing STARTTLS correctly is challenging. We therefore recommend avoiding STARTTLS when possible and ideally deprecating it in the long term, at least for client-to-server communication. This recommendation is in line with RFC 8314, which already recommends preferring implicit TLS on its own ports over STARTTLS.

For server-to-server connections, avoiding STARTTLS is currently not possible because no mechanism to use implicit TLS directly is specified.

Short news

• Mozilla announced that starting with Firefox 90, client certificates provided by the operating system (on MacOS and Windows) will automatically be offered on sites requesting TLS client authentication.
• A vulnerability in Lynx could leak HTTP basic authentication passwords passed through the URL via the TLS SNI extension.
• The thunderbird.net website, used among other things for Thunderbird add-ons, had an expired certificate, leaving the site unavailable for a few hours.
• In its latest release, the acme.sh tool changed its default CA from Let’s Encrypt to ZeroSSL. This was announced earlier this year.
• OpenSSL fixed two security vulnerabilities with its latest release, 1.1.1l: a buffer overflow in the SM2 decryption function, and buffer overreads in some ASN.1 string-processing functions.
• Firefox will soon block mixed-content downloads, meaning downloads from an HTTPS web page that go to an HTTP URL. A similar change was made in Chrome in the past.
• GitHub announced that it plans to disable the old TLS versions 1.0 and 1.1 for the npm registry.
• Soatok’s blog, which is always a good resource for cryptographic insights, has posts about canonicalization attacks and different kinds of hash functions available this month.
• The Chrome developers announced that they have removed support for the Triple-DES (3DES) CBC mode cipher suite. Triple-DES was shown to be problematic due to its small block size in the Sweet32 attack in 2016.
• Firefox announced that it will use HTTPS by default in the private browsing mode.