STARTTLS considered harmful

The use of Transport Layer Security (TLS) encryption is ubiquitous on today's internet, though that has largely happened over the last 20 years or so; the first public version of its predecessor, Secure Sockets Layer (SSL), appeared in 1995. Before then, internet protocols were generally not encrypted, thus providing fertile ground for various types of "meddler-in-the-middle" (MitM) attacks. Later on, the STARTTLS command was added to some protocols as a backward-compatible way to add TLS support, but the mechanism has suffered from a number of flaws and vulnerabilities over the years. Some recent research, going by the name "NO STARTTLS", describes more, similar vulnerabilities and concludes that it is probably time to avoid using STARTTLS altogether.

Opportunistic TLS

Normally, protocol messages are either encrypted or not, but STARTTLS allows for a kind of middle ground. It is the command used to invoke TLS for an existing plaintext connection in what is known as opportunistic TLS. Servers can advertise their ability to handle TLS connections; for example, an email (SMTP/ESMTP) server specifies whether it will accept the STARTTLS command in its reply to the client's initial message (EHLO). If desired, the client can then request encryption using the STARTTLS command; a TLS handshake will then be performed and subsequent traffic will be encrypted. This contrasts with implicit TLS, where the communication channel, typically indicated by a specific port number, only operates in the encrypted mode.

As might be guessed, it is the switch from one mode to the other that is most vulnerable to MitM attacks. In the most basic attack, known as STARTTLS stripping, an attacker who can intercept and change the traffic can simply stop any STARTTLS command from being sent between the participants, ensuring that the conversation proceeds in plaintext form. Failure to establish an encrypted session could be treated as an error by clients, but sometimes is not. The next step after trying to establish the encryption is often some kind of authentication, which might effectively be performed in plaintext if the session is not encrypted.

As reported by one of the researchers, Hanno Böck, on the oss-security mailing list, a STARTTLS flaw found in 2011 was the jumping-off point for the research. That flaw was found by Postfix creator Wietse Venema in multiple SMTP servers, including Postfix; it allowed MitM attackers to "inject plaintext content into the TCP packet of a STARTTLS command and a server would interpret it as if it was part of the TLS session", Böck said. But the researchers found that this ten-year-old vulnerability was still unfixed in some servers; in its most severe form, "it can be used for credential stealing".

The other researchers, Damian Poddebniak, Fabian Ising, and Sebastian Schinzel, are from Münster University of Applied Sciences, while Böck is an independent researcher. They presented their paper at the 30th USENIX Security Symposium in August. As part of that work, they developed a testing toolkit called EAST that was used to analyze 28 email clients and 23 servers; only three of the clients and seven of the servers were completely unaffected by the 40 separate STARTTLS problems they uncovered. In addition, it turns out that 15 servers are still vulnerable to the same flaw found by Venema in 2011; scans found that 2% of mail servers on the internet exhibit the flaw. Both the paper and the web site have more details on all of the flaws, including which servers and clients are affected.

The researchers also looked at the POP3 and IMAP message-retrieval protocols, both of which have STARTTLS commands. Like what Venema saw for SMTP, they found that some servers will process the plaintext sent with the command as if it were part of the encrypted session. Instead of discarding any buffered input, the servers end up processing it after the TLS handshake is done—and the state of the connection has changed.

The most severe attacks exploit this behavior to exfiltrate the user's login credentials. They require that the attacker also has a valid account on the SMTP or IMAP server in question, though, which reduces the scope of the problem somewhat.

The attacker can inject commands that authenticate them and then start sending (SMTP) or storing (IMAP) an email. The login credentials sent by the victim will be stored in the email that the attacker can access.

Going in the other direction, mailbox contents can be forged by adding commands to the STARTTLS response from the server. Once again, the data is buffered and interpreted in the context of the encrypted session, this time by the email client, even though it was sent (and received) before the session was established.

This bug affected many popular mail clients, including Apple Mail, Mozilla Thunderbird, Claws Mail, and Mutt.

By injecting additional content to the server message in response to the STARTTLS command before the TLS handshake, we can inject server commands that the client will process as if they were part of the encrypted connection. This can be used to forge mailbox content.

On the web page for the NO STARTTLS flaws, the researchers called out a third vulnerability type that was found. In IMAP connections, the PREAUTH command can be sent by a server to indicate that the client is already authenticated, but it also prevents the client from using STARTTLS to transition into an encrypted state. The IMAP protocol does not allow STARTTLS after PREAUTH, which turns PREAUTH into a way to prevent encryption that is somewhat similar to STARTTLS stripping. Clients should reject that type of connection when encryption has been requested by the user, but some do not. The flaw was found in the Trojitá email client in 2014, but the researchers discovered that other clients are vulnerable to it.

When coupled with the little-used IMAP referral features (for logins and for mailboxes), an attacker could cause a client to send its credentials directly to the attacker:

By using PREAUTH to prevent an encrypted connection, an attacker can use referrals to force a client to send credentials to an attacker-controlled server. Fortunately, the referral features are not supported by many clients. We found only one client - Alpine - vulnerable to this combination of PREAUTH and referrals.

Recommendations

The researchers recommend that users stick to implicit TLS ports (465 for SMTP submission, 993 for IMAP, and 995 for POP3) to avoid STARTTLS altogether, though some service providers do not give that option for email submission. Application developers should strongly consider only offering support for implicit TLS; if that is not possible, testing with EAST or something similar is needed to ensure that plaintext is not processed as if it were encrypted. Meanwhile, mail-server administrators should consider disabling STARTTLS for the email-handling protocols.

As noted in the FAQ section, STARTTLS is the only way for mail servers (mail transfer agents or MTAs) to encrypt the traffic between themselves, as there is no support for implicit TLS for SMTP when it is used to transfer email between MTAs. Those STARTTLS transactions are already vulnerable to STARTTLS stripping attacks, because servers do not know whether the other endpoint accepts TLS or not; they cannot refuse to transfer mail because the connection is not encrypted. That means there is no real advantage for attackers to adopt the NO STARTTLS techniques. Adding authentication to the connections between servers, which is being worked on, would change the equation, however, so server code needs to be analyzed for buffering and other types of STARTTLS problems.

MitM vulnerabilities that can only be exploited with the ability to alter messages between the endpoints are sometimes seen as "lesser" flaws—and they are. But the requirements for an active meddler in between the participants are sometimes misjudged. For example, any WiFi router, say at the local coffee shop, or internet service provider being used, certainly has the capability of performing these kinds of attacks—it does not require some nation-state attack against the internet backbone by any means. WiFi routers, especially those in busy locations that handle lots of users, would make prime targets for a full compromise by an attacker. That compromise would provide a perfect platform for MitM attacks of various sorts against all of its users.

While the NO STARTTLS vulnerabilities are important and should be fixed, they are not generally huge problems in their own right. Their impact is fairly limited as the researchers noted:

The demonstrated attacks require an active attacker and may be recognized when used against an email client that tries to enforce the transition to TLS. We have informed all popular email client and server vendors and most issues are already fixed. We think that the demonstrated attacks would be difficult to execute on a large scale and we primarily expect them to be used in targeted attacks.

One thing the vulnerabilities do highlight is that projects are not generally all that good at scrutinizing their code for the same kinds of problems found in other, similar tools. Vulnerabilities found years ago should quite plausibly have led other email server and client projects to ferret out their own manifestations of those bugs long before now. Instead, it took some security researchers who were curious about the wart that is STARTTLS.

It is clear that retrofitting security into existing protocols is difficult to get right. Mixing plaintext and encrypted traffic over the same connection without these kinds of botches is evidently difficult as well. Those general principles will be important to keep in mind as we move forward; backward compatibility is most certainly a "nice to have", but secure protocols, without warts and hard-to-get-right pieces, is increasingly becoming a "must have".

port  % of connections
25	60.5
465	24.8
587	14.6