« blog index

Stronger Email Security with SMTP MTA STS: Strict Transport Security

July 25th, 2018

Email transmission between servers has historically been extremely insecure. A new draft internet standard called “SMTP Strict Transport Security” or “SMTP MTA STS” is aiming to help all email providers upgrade to a much more secure system for server-to-server mail transmission. This article lays out where we are currently in terms of email transmission security and how SMTP MTA STS will help.

Email servers (a.k.a. Mail Transmission Agents or “MTAs”) talk to each other using the Simple Mail Transmission Protocol (SMTP). This protocol, developed in 1982, originally lacked any hint of security. As a result, a lot of the email shooting around the internet is still transmitted in plain text.  It is easily eavesdropped on, easily modified, untrusted and not private.

Back in 2002, an extension to SMTP called “STARTTLS” was standardized. This extension permitted servers to “upgrade” SMTP communications from plain text to an encrypted TLS-secured channel, when both servers supported compatible levels of TLS. This process is known as SMTP TLS. In principle, this security addition was really great. The “TLS” used is the same encryption method used by your web browsers to talk to secure web sites (e.g., banks, Amazon, your email provider, etc.). Your web browsers do relatively good job making sure that connections to these secure sites are safe.  I.e., they seek to ensure that there is encryption, that the encryption is sufficiently strong, and that there is no one actively eavesdropping on your connections.

The security problems with SMTP TLS

In order for TLS-based encryption to be used, two main things must be setup on inbound email servers:

  1. A TLS certificate. This is a public key/private key pair that enables an encrypted connection to be established on demand. The certificate contains within itself a list of domain names that it is supposed to protect. It can also be signed by a trusted third party who is supposed to verify that the certificate holder has a right to protect communications to those domain(s). (More on TLS Certificates.)
  2. TLS protocol and cipher configuration. The TLS encryption protocol has evolved over time and there are many different mathematical methods for encrypting information. The choices made by the server administrator with respect to which encryption methods (ciphers) will be supported and which versions of the TLS protocol are installed have a large impact on the potential strength of any secure connections made to the server.

Unfortunately for the prospect of universally great TLS-based email security, it is very common to find email servers setup with:

  • Expired TLS certificates.
  • TLS certificates that do not match the domain names of those servers.
  • TLS certificates that are not even issued by trusted third parties.
  • Support for very old TLS protocols and/or lack of support for “new” protocols (like TLS v1.2+)
  • Support for very weak/poor encryption ciphers and/or lack of support for the new and really good ones.

 

 

Fortunately, when two servers communicate using TLS, they will generally agree one of the most secure combinations of TLS protocol and cipher mutually supported. However, that still leaves us with the following serious security issues facing SMTP TLS:

  1.  If one of the servers only supports weak ciphers and/or old TLS protocols then either:
    1. No encryption: There will be no mutually agreed upon encryption method and the communications will be in plain text, or
    2. Weak encryption: The encryption used will be very weak / insecure. A passive eavesdropper (i.e., someone who can listen to the communications but not modify it) may be able to record the transmission and decrypt it.
  2. No authentication. Because the TLS certificates are often invalid or not trusted, the TLS certificates are generally not verified by the sending servers. The sending servers have no proof that they are actually talking to the server to which they are trying to connect.
  3. Man-in-the-middle: If the there is an active man-in-the-middle (i.e., someone between the 2 servers that can read and change the transmission as it happens):
    1. The servers may never know it.
    2. The man-in-the-middle will be able to read all traffic.
    3. The man-in-the-middle will be able to modify all traffic.
    4. The man-in-the-middle could modify the transmissions to remove TLS encryption or to force use of a very weak cipher or protocol.

In short — traffic to really old/poorly configured mail servers can be passively eavesdropped on and any man-in-the-middle between the two email servers could have full access to the transmitted email data.

How bad is it?

LuxSci examined the set of all domains to which LuxSci customers are sending email in June/July, 2018. Only 82.3% of those domains had what LuxSci considers “minimally sufficient SMTP TLS support“.  I.e.,

  • All inbound email servers are working.
  • All inbound email servers actually support SMTP TLS.
  • All inbound email servers support TLS 1.0+ and at least some good ciphers from the NIST 800-52 r1 or r2 lists.

This means that 17.7% of the domains to which people are sending email do not have any TLS support or are in some way seriously deficient. For SMTP STS, the bar is higher than “minimally sufficient.” The inbound email servers for domains participating in Strict Transport Security must also support TLS v1.2 and utilize TLS certificates that properly validate and are trusted.  Looking at all the “minimally sufficient” domains, LuxSci found that 98% of them do support TLS v1.2; however, only 76.8% of them have TLS certificates that can be validated and trusted.

So — a significant number of domains still do not have usable TLS for inbound email and about a quarter of those that do can not be trusted. Email service providers need to start with updating the TLS certificates used by their email servers.

Is this News?

This is not news. These security issues are all very well known in the security and email community. Indeed, many email providers have various small-scale work arounds. For example:

  1. LuxSci’s “Forced TLS” service automatically checks all of the MX records for a domain to make sure that all of them support TLS and good ciphers (i.e., have “minimally sufficient SMTP TLS”). It then locks down its configurations so that email will not go to that domain without good TLS encryption. This prevents insecure email delivery due to server misconfiguration or protocol downgrades.
  2. Some providers allow you to manually “Force TLS” on a per-domain basis by specifying domains to which email must be delivered over TLS.
  3. Some providers also allow you to manually enable TLS certificate verification on a per-domain basis to prevent many types of man-in-the-middle attacks. Of course, this requires that the recipient’s email servers actually have their TLS certificates setup properly and also requires a lot of continuous manual work.

Enter: SMTP MTA STS: Strict Transport Security

The SMTP MTA Strict Transport Security draft specification is designed to address many of these security issues without breaking the existing email infrastructure. Here is an overview of how it works.

Inbound Email Server Providers:

Organizations with inbound email servers (i.e., servers that receive email from others) can update their SMTP TLS configuration to modern good-security standards. Let’s say the organization in question is updating the email servers for the domain “example.com.” I.e., email to “anyone@example.com” would be delivered to these servers. The organization would:

  1. Update all of their inbound email servers to support SMTP TLS
  2. Make sure all of these inbound email severs support TLS Protocol v1.2
  3. Make sure that their TLS certificates:
    1. Are not expired.
    2. Match the domain name used by their inbound email server (as per the DNS MX records for example.com).
    3. Are signed by a trusted third-party TLS certificate authority.

Then, they can follow the SMTP MTA STS guidelines to publish the fact that their servers are well configured:

  1. They create a special DNS TXT record for “_mta-sts.example.com”
  2. They setup a secure web site, “https://mta-sts.example.com” with a valid TLS certificate signed by a trusted third party
  3. They publish a text file under the address “https://mta-sts.example.com/.well-known/mta-sts.txt”
    1. This text file will, among other things, list all of the SMTP-TLS-supporting MX records used by example.com

Outbound Email Server Providers

Servers that are sending outbound email can take advantage of the new SMTP MTA STS specification to enhance the security of communications with inbound email providers that also support SMTP MTA STS. To do this they would:

  1. Check and see if SMTP MTA STS is supported by the recipient. I.e., for email to “anyone@example.com”
    1. Check and see if the DNS TXT record for “_mta-sts.example.com” exists and is setup properly.
    2. Read the file published at “https://mta-sts.example.com/.well-known/mta-sts.txt”
  2. Read the DNS MX records for example.com to see what servers accept example.com’s email.
  3. Sort those inbound email servers by their priority
  4. Deliver the email:
    1. Prepare to connect to on of example.com’s inbound email servers
    2. See if that email server is listed in the example.com’s STS configuration file
    3. If it is, then:
      1. Use TLS 1.2 with it, and
      2. Verify the TLS certificate
      3. If there is any failure in 1 or 2 … do not deliver the email
    4. If it is not:
      1. Send the email via the usual methods.  This could result in insecure or secure email delivery.

We have left off the minor details of the SMTP MTA STS protocol for simplicity. However, as you can see Strict Transport Security paves the way for (a) recipient servers to upgrade their security, (b) recipient servers to securely inform sending servers that they are support STS-levels of transmission security, and (c) sending servers to discover this information and to use it to enhance the security of SMTP connections over TLS and to protect them from most of the deficiencies in the current state of SMTP TLS usage across the internet.

SMTP MTA STS also allows the current email delivery ecosystem on the internet to function “as is” while security improvements are bootstrapped as providers gradually implement support for Strict Transport Security.

What are the down sides of SMTP MTA STS?

The folks that have been working on SMTP Strict Transport Security have done a pretty good job at heading off many of the potential issues that could arise. Of the issues that remain, some of these include:

  1. Loss of email. If your enable STS and one or more of your inbound email servers is not appropriately configured, you will lose email until you fix the server or adjust your STS configuration. This is not a big concern as STS configurations can be adjusted very quickly.
  2. Injected MX records. If an attacker can modify the DNS responses received by the sender’s servers, the attacker can possibly add MX records that are not covered by STS and which will deliver email to the attacker’s own server.
  3. Blocked TXT records. If the attacker can modify the DNS responses received by the sender’s servers, the attacker can block the STS TXT record. This can cause the sender server believe that the recipient’s domain does not support STS (depending on the state of the sender’s STS cache).
  4. Rogue TLS Certificates. If an attacker can get a TLS certificate signed by a trusted third party for the recipient’s domain, then the attacker can still be an active man-in-the-middle.

So, while SMTP MTA STS is not perfect, it does significantly reduce the range of possible attacks on TLS-secured email transmissions while also encouraging email providers to make sure that their SMTP TLS support is well configured.

How to check if a domain support SMTP Strict Transport Security

It is easy to check the SMTP TLS security implementation, including SMTP MTA STS support, for any particular domain. Simply, enter the domain to check in the following “TLS Checker:”

SMTP TLS Checker

 

How does LuxSci use SMTP MTA STS?

LuxSci’s inbound email servers all support TLS v1.2, strong TLS ciphers, and their TLS certificates validate. LuxSci has enabled SMTP MTA STS for its primary domains: luxsci.com, luxsci.us, and luxsci.net. We can assist any of our customers in setting Strict Transport Security up for themselves as well (though a secure web site will be needed).

Additionally, LuxSci is updating the dynamic Forced TLS email delivery process included with its SecureLine email encryption service to be MTA STS-aware. In additional to only using strong ciphers for email delivery (which is already the case), LuxSci will automatically require TLS certificate validation for email delivery over Forced TLS to any recipient whose servers have SMTP MTA STS enabled. No end-user configuration is required — the security enhancement happens automatically and seamlessly in the background.

This entry was posted on Wednesday, July 25th, 2018 at 11:51 am and is filed under LuxSci Library: Security and Privacy.