A new Internet standard called MTA-STS gives email servers a way to create secure, encrypted connections to deliver mails and validate certificates. Encryption was already possible before, but it has several flaws. This new standard also seems to solve some GDPR compliance issues.
When an email is sent, it usually involves three network connections: One from the sender’s device to his mail server, one from the sender’s mail server to the recipient’s mail server and one from the recipient’s mail server to the recipient himself, that is his local device. The first and the third connection usually happen either through a web interface, as most people use front ends like Gmail these days, or through a mail application with a combination of protocols.
The Internet standardization organization IETF has recently published a standard that may help closing one of the biggest gaps in email security: Unencrypted connection between mail servers. The new standard that is called MTA-STS provides a secure and encrypted method for connections between mail servers. It has the support of major industry players like Google and Microsoft and thus has chances of being more successful than previous attempts at solving the problems of data confidentiality.
Usually, these two connections at the beginning and the end are already secure. Web interfaces of all major mail providers use HTTPS and modern mail clients usually use the TLS-encrypted variants of the email protocols that have been available for a long time. Most mail providers have even stopped supporting the unencrypted versions of these protocols.
However, when it comes to the connection between mail servers things get difficult. Let us take an example where a user who is using Gmail wants to send a mail to someone using Yahoo Mail. Obviously a network connection needs to happen between Gmail’s and Yahoo’s servers. These connections use a protocol called SMTP.
SMTP was originally a plain text protocol. That means that anyone who can control a server that sits in between two mail servers can simply read your e-mails if sent via the original SMTP. Such person could for example be a malicious employee at an Internet infrastructure company operating between two mail providers.
Encryption between email servers exists since 2002 – but it has flaws
In 2002 an extension to SMTP was published which is using a technology called STARTTLS. This allows for encrypted connections. One mail server can include a command in the connection that indicates that it supports this encrypted mode and then both mail servers can upgrade their connection to use encryption.
But there’s a problem with STARTTLS: For backwards compatibility reasons it is entirely optional. This gives an attacker who controls the connection between two mail servers a very simple method to prevent the encryption from happening. He can just remove the STARTTLS command that initiates the encryption from the connection. The two mail servers will then communicate in plain text again and the attacker will be able to read along.
Also, traditionally mail servers didn’t care that much about validating certificates. Many servers use certificates that are invalid, e.g. expired or issued for the wrong name.
This existing form of server-to-server encryption is better than nothing. It will stop attackers who merely record a connection and do not manipulate it. But it does not help against the latter category of attackers.
The new standard MTA-STS is trying to change that. It gives mail servers a way to publish a policy which indicates how other mail servers should check their certificates. These policies are published on a web host via HTTPS.
Server operators who want to implement MTA-STS need to do two things: They need to indicate that they have a policy via a DNS record and they need to setup a web host that provides the actual policy. Explaining how these DNS records and policies look is beyond the scope of this article, but you may want to have a look at an existing policy, for example the one from Gmail.
The crucial part here is that the policy is provided via HTTPS with a valid certificate. If you want to host a policy for the domain example.org it would end up on mta-sts.example.org. Only the legitimate owner of example.org should be able to create a valid certificate for this host. This guarantees that an attacker cannot publish a rogue policy and thus attack the protocol.
It should be noted that MTA-STS does not protect mails from the mail provider itself. This means that for example a rogue employee at a mail provider can still illegitimately read emails, as the encryption only happens between mail providers. End-to-End encryption, for example using OpenPGP or S/MIME, can help against such attack scenarios, but it hasn’t seen widespread adoption, as it is relatively complicated.
You will find TRUSTZONEs S/MIME solutions here.
Other protocols that are using cryptography to protect emails are DKIM and DMARC, however they serve a different purpose. They use digital signatures to try to prevent forgery of sender addresses, but they don’t encrypt data and thus don’t provide confidentiality.
MTA-STS takes over where Dane didn’t succeed
MTA-STS is not the first attempt to solve encryption between mail servers. A protocol with the name DANE tried to achieve something similar, however it was built on top of the DNS system and a technology called DNSSEC.
DNSSEC is controversial, many in the security community believe it is too complicated to be useful in practice. Discussions about it often get heated quickly. However, there is one undeniable fact: Large email service providers like Google and Microsoft have not adopted DNSSEC and DANE – and a large share of the email marked remains unprotected by those technologies.
It is likely that MTA-STS will have more success than DANE. The protocol was created in close collaboration with large mail providers, so they will probably adopt it. The authors of the standard include employees from Google, Microsoft, Yahoo and Comcast. These companies combined run a large share of the email market.
If you want to check whether your email host already supports MTA-STS you can use the service Hardenize. It contains a check for MTA-STS and also tells server operators if their configured policy contains any errors.