When email client applications communicate with mail servers, the protocols they use to communicate (POP3, IMAP and SMTP) support two ways of encrypting the connections with Transport Layer Security (TLS). Each protocol supports connections that are directly encrypted via TLS on a different port — 995 for POP3, 993 for IMAP and 465 for SMTP. Alternatively, the unencrypted variants of these protocols can be upgraded to encrypted connections via a mechanism called STARTTLS.
This upgrading of connections comes with many potential security pitfalls. Together with researchers from the Münster University of Applied Science, I was involved in research recently published at the USENIX security conference in which we systematically analysed STARTTLS vulnerabilities. During this research, we found more than 40 STARTTLS-related security flaws in many different software products, both client-side and server-side.
Vulnerabilities exist in many email clients
In the past, STARTTLS has sometimes been used as an opportunistic encryption mode. This means that a client would upgrade a connection if the server offers the STARTTLS feature, however, it would still connect if it is not available. This opportunistic use of STARTTLS is trivially vulnerable and is usually not used today.
But even in a more strict mode where a client terminates connections if an upgrade via STARTTLS is not possible, it comes with many security problems.
In 2011, Postfix developer Wietse Venema discovered that in some STARTTLS server implementations, it is possible to inject plaintext commands that the server would treat as if they were part of the encrypted connections. This works by attaching additional commands to the TCP packet that sends the still unprotected STARTTLS command.
In our tests, we learned that this command injection vulnerability from 2011 is still very prevalent. Several large email providers, including GMX, Interia.pl and Yandex, were vulnerable to this flaw. We also showed how to practically exploit this vulnerability in SMTP and IMAP. If an attacker has a valid account on the same server as the victim, it is possible to store mail in the attacker’s mailbox that contains the login credentials of the victim.
The following shows an example of credential-stealing in SMTP: Redirecting mails and user credentials on an SMTP server. Text marked in blue will be interpreted as the DATA of the mail.
// 1) Attacker injects multiple commands (A, B, ...) to
// prepare the transmission of an email.
// The commands will generate multiple responses,
// which will conveniently make the client send
// more commands.
S: 220 OK
// ...
C: STARTTLS
A: EHLO attacker // A
.. AUTH PLAIN <attacker login> // B
.. MAIL FROM:<attacker@example.com> // C
.. RCPT TO:<attacker@example.com> // D
.. DATA // E
S: 220 OK
// ------------------ TLS Handshake -------------------
// 2) A-E are interpreted here. The server is now in a
// state to accept an email body. All following lines
// from the client are misinterpreted as an email,
// which is then send to attacker@example.com.
C: EHLO alice
S: 250-mail.example.com // A
.. 250 AUTH PLAIN LOGIN
C: AUTH PLAIN <alice login>
S: 235 OK // B
C: MAIL FROM:<alice@example.com>
S: 250 OK // C
C: RCPT TO:<bob@example.com>
S: 250 OK // D
C: DATA
S: 354 OK // E
C: <email to bob>
.. .Furthermore, we learned that a very similar type of vulnerability exists in many email clients. We called this a response injection. This STARTTLS response injection allows an attacker to forge mailbox content.
We also analysed an incompatibility of the IMAP protocol’s ‘PREAUTH’ feature and STARTTLS. This was originally found in the Trojita mail client, but as we found out, it affected many other clients too.
Directly after a new client connection, an IMAP server can signal to the client that it is already authenticated and does not need to send login credentials. This is signalled by the PREAUTH keyword. However, the standard says that a STARTTLS command can only be sent in the unauthenticated state of the protocol. Therefore PREAUTH and STARTTLS are inherently incompatible. In affected mail clients, this allowed an attacker to enforce an unprotected connection by the client.
Prefer implicit TLS
All the above vulnerabilities stem from the fact that STARTTLS introduces a state transition between an unencrypted and encrypted connection that is error-prone. But all three email protocols also offer a direct TLS connection — so-called implicit TLS. This completely avoids the error-prone state transition and should thus be preferred. We were not the first to recognize this. RFC 8314, published in 2018, recommends that implicit TLS versions of the email protocols should be preferred.
But despite this recommendation, there are still major mail server providers that do not offer implicit TLS for all protocols. Most notably, the email services from Microsoft and Apple don’t offer TLS-encrypted SMTP email submission on port 465.
We recommend that server operators of mail services make sure they offer the implicit TLS versions of all three email protocols. We also recommend that mail server operators consider completely disabling the plaintext and STARTTLS variants of these protocols.
We recognize, however, that this is difficult for server operators with an existing user base, as all users who have configured STARTTLS would need to change their configurations. For new servers, however, this should be the preferred choice.
Ideally, future mail clients would neither offer unencrypted nor STARTTLS connections and just always use implicit TLS. This would avoid the need for any TLS-related configuration.
Our research focused mostly on client-to-server communication. However, STARTTLS in SMTP is also used in email server-to-server communication. Unfortunately, with existing standards, there is currently no way of using TLS encryption in an implicit TLS mode for these server-to-server SMTP connections. The only way is, therefore, to carefully audit email server STARTTLS implementations for security flaws.
Traditionally, STARTTLS in server-to-server connections was merely an opportunistic security mechanism, not protecting against active attackers. However, mechanisms like MTA-STS and DANE try to change that, so securing STARTTLS implementations becomes important for servers, too. We have provided test tools that can help to find STARTTLS flaws.
Hanno Böck is an independent researcher and IT journalist working for the German publication Golem.de.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.