What You Need to Know about SMTP Strict Transport Security


Thought Leadership

What You Need to Know about SMTP Strict Transport Security

Dave Robertson

Recently, a number of articles (like this one in InformationWeek) touched on the new, proposed SMTP Strict Transport Security (STS) standard and how it will help secure email communication. Zix applauds the development of this new standard and its potential to address some of the current security vulnerabilities of TLS. But for an in-depth perspective of STS, we need to understand what STS is changing, how STS benefits email users and what security gaps remain despite this great advancement.

To get us started, let’s review the methods and more importantly the flaws of TLS.

TLS (Transport Layer Security) is implemented through two methods – Mandatory and Opportunistic. Mandatory TLS requires a TLS connection be present before sending an email. If a TLS connection cannot be ensured on the recipient end, then the email is bounced. Mandatory TLS is the safer TLS method, however it requires each TLS connection be set-up and authenticated manually. As a result, it is cumbersome, costly and time consuming.

Opportunistic TLS does not have the time or resource costs of Mandatory TLS. However, it introduces significant security and compliance risks. Because SMTP was built long before the concept of SSL/TLS, SMTP over Opportunistic TLS was enabled by adding a new optional command, called STARTTLS. If the receiving mail server understands the STARTTLS command, then a TLS connection can be established.  If not, then the command is ignored, and the email is sent in the clear.

The problem is that this approach is subject to a man-in-the-middle downgrade attack. A man-in-the-middle can intercept the STARTTLS command and return garbage, causing the servers to assume TLS is not available and deliver the email in plaintext, for example.

Another issue with the use of STARTTLS is that the Request for Comments (RFC) does not require the certificate used to verify the server to match the mail domain but instead allows the certificate to just match the name of the server in the MX record. This would not be an issue if there were a way to digitally sign and verify the MX record to ensure the MX record and associated server belong to the domain. Because this is not available, attackers can provide alternative MX records for servers they own. The sender and receiver believe they are communicating over TLS when in reality they are communicating via TLS to the attacker’s server.

The proposed SMTP STS standard addresses these two TLS attacks, greatly improving the security of TLS.

ISPs and receiving mail servers will be able to publish whether they support TLS, information to verify the TLS certificate and what to do if a TLS connection cannot be established. The options if a TLS connection cannot be established will include the ability to report or fail (bounce). In the case of reporting, the sending mail server will be able to send information about the failure to the receiving mail server but still deliver the mail in clear text (opportunistic TLS). When the fail option is set, the TLS transport is effectively ‘mandatory’.

These improvements will likely increase the use of TLS for general email communication. Yet it does not solve the issue of companies required or concerned with protecting personal information in email communications. Stay tuned for the second blog post in our STS series when we cover why STS is not enough to protect every email and every email user.