Safe Transport

Communication needs privacy. It forms the basis for confidential and binding exchange. A typical email does not offer any privacy as it passes through the network in cleartext. Anyone who reads the network traffic has full access to the content of the message, so anyone who wants privacy needs encryption. PGP and S/MIME or SSL and STARTTLS are suitable methods for encrypting email. The first two methods encrypt the message; the others encrypt the transport.

Not Always Safe Transport

Transport encryption (Transport Layer Security, TLS) is attractive. It provides a useful level of protection and is transparent to the user. That is good because it saves support costs and allows users to concentrate on the contents of the communication rather than the encryption.

Many admins believe it is sufficient to generate the required certificates for encryption and enable STARTTLS in the SMTP Server and Client (Figure 1). They think that the transport is safe from then on. They are wrong. Transport encryption has some principle-related vulnerabilities, which this article discusses and justifies.

Figure 1: It is not enough to enable SSL/TLS in the mail client, because by default all participants use encryption-free communication as a fallback – and this can be provoked.

Session Downgrade

STARTTLS is a protocol extension of the original SMTP. Two conditions must be met to establish a TLS-protected connection. The server must both have control over and offer ESMTP (Extended SMTP), and the STARTTLS extension must be enabled in the server.

A client will only know whether these conditions are met if the server sends its "SMTP Banner" to greet the client. In the banner, the server establishes its current status through a status code, often followed by its name and – importantly – the string ESMTP (Listing 1).

$ telnet mail.sys4.de 25
220-mail.sys4.de ESMTP Postfix
EHLO client.example.com
250-mail.sys4.de
250-PIPELINING
250-SIZE 40960000
250-ETRN
250-STARTTLS
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

If the server does not send an ESMTP in the banner, then it does not (or at least appears not to) support ESMTP, and communication can only take place without transport encryption. If the string is missing or the server sends SMTP, then the client must assume that the server does not have control over any SMTP extensions.

The SMTP clients in popular mail servers are generally set unconditionally to transport. They perform "opportunistic TLS." In other words, they try to bring about encrypted transport if the server provides STARTTLS. They switch back to the original SMTP if ESMTP is missing in the server's banner. You do without transport encryption because there is no "opportunity" to use it.

Security solution providers benefit from this behavior just as some access providers do. They filter SMTP connections in the firewall (called SMTP fixup by Cisco), in the desktop SMTP proxy (McAfee), or on WAN connections [1] and remove the ESMTP in the banner.

Specifically Insecure

The providers receive access to the session data and the contents of the message using this deliberately administered session downgrade. According to them, a message can only be checked for malicious content (malware, spam) if unencrypted. In this case, this argument is not tenable: Messages can also be transported unencrypted to the server and then checked for undesired contents unencrypted in the server. This is exactly what happens a million times a day.

Conspiracy theorists may speculate about possible reasons against the backdrop of the NSA affair, but the fact remains: Transport encryption provides an attack vector that is applicable, for example, with the STRIPTLS attack [2]. Such attacks are possible because conventional TLS does not provide policy components. The server does not have a tamper-proof channel through which it can indicate to the client that it has control over STARTTLS. Only your own TLS policy and enabling another SMTP extension can provide help here.