Blog
Welcome to the Hardenize blog. This is where we will document our journey as we make the Internet a more secure place and have some fun and excitement along the way.
Update (23 April 2019): Gmail has become the first major email provider to support MTA-STS and TLSRPT, making it easier to justify deploying these new standards. More information is available in their blog post.
Update (26 Sep 2018): MTA-STS has been officially published as RFC 8461.
MTA-STS (full name SMTP Mail Transfer Agent Strict Transport Security) is a new standard that aims to improve the security of SMTP by enabling domain names to opt into strict transport layer security mode that requires authentication (valid public certificates) and encryption (TLS). In this blog post we discuss why MTA-STS exists and how it's used, as well as announce full support for its most recent draft in Hardenize.
Traditionally, a big security problem with SMTP is that encryption is entirely optional. When support for upgrading from plaintext to encryption in the form of the STARTTLS command was added to SMTP (RFC 3207), the specification explicitly specified that SMTP servers must accept plaintext connections. Here's the relevant text:
A publicly-referenced SMTP server MUST NOT require use of the STARTTLS extension in order to deliver mail locally. This rule prevents the STARTTLS extension from damaging the interoperability of the Internet's SMTP infrastructure.
Thus, without further work, our current SMTP infrastructure can defend only against passive attacks. Although that's extremely valuable when compared to the plaintext-only alternative where email is globally passively recorded at massive levels, it leaves a lot to be desired if you're important enough to be targeted directly via active network or man-in-the-middle (MITM) attacks.
How would that work? For example, SMTP connections typically start as plaintext; if a MITM can intercept a connection, they can suppress the STARTTLS upgrade, making it seem that the target server doesn't support encryption. Another possible approach is to intercept DNS queries and simply respond to MX queries with a list of attacker-controlled email servers. In this scenario, the client would be delivering all email directly to the attacker and they could enable encryption, too. After observing the emails, the attacker can then deliver them to the real email servers.
MTA-STS defeats both of these attack vectors; it's a signalling mechanism that enables domains to achieve two things: 1) first opt into robust transport layer security and then also 2) securely communicate what their MX servers should be. MTA-STS has a memory effect; the policy is activated on the first visit and remains active for the specified duration.
MTA-STS has been in development for about two years. The draft version 21 was approved as proposed standard. It's expected that the standard will have support of the big email providers, such as Google, Microsoft, and Yahoo. Of these, Google currently has an earlier version of MTA-STS configured, Microsoft doesn't, and Yahoo indicates support but doesn't actually have a policy.
If you follow network security standards you may already aware of other similar efforts in this space, namely DNSSEC and DANE. DNSSEC is an effort to add integrity to DNS so that everyone can use cryptography to verify that the DNS information came from the domain name owner. With DNSSEC you can have DNS results that you can always trust to be correct. DANE builds further by creating a bridge to bootstrap security for higher-level protocols, for example SMTP.
It sounds great in theory, but in practice the world is divided into two factions, one that wants to use DNSSEC and another that doesn't. The feud, if we can call it that, has been going on for a number of years without an end in sight. In essence, the group that doesn't wish to deploy DNSSEC decided they wanted to solve the email security problem using a different approach, and thus MTA-STS was born.
This is even spelled-out in the MTA-STS specification, which also explicitly states that there shouldn't be any interference with DANE if it's deployed:
The primary motivation of MTA-STS is to provide a mechanism for domains to ensure transport security even when deploying DNSSEC is undesirable or impractical. However, MTA-STS is designed not to interfere with DANE deployments when the two overlap; in particular, senders who implement MTA-STS validation MUST NOT allow a "valid" or "testing"-only MTA-STS validation to override a failing DANE validation.
A couple of days ago, the EFF announced another in their line of "Everywhere" projects, this one called STARTTLS Everywhere. Their goal is also to improve the security of email infrastructure, essentially by building a list of servers that are guaranteed to support strict transport mode. In the context of MTA-STS, the EFF is effectively hosting a preload list, like Google is doing for HTTP Strict Transport Security (HSTS).
Deploying MTA-STS it not very difficult, but requires several steps. The first step is obvious: enumerate all your mail servers and ensure they support TLS and that they are equipped with valid publicly-trusted certificates.
The second step is to publish your MTA-STS policy. Unusually, this is done by placing your policy on
a web server, in a well-know location and on a host with a special hostname. The certificate on the
server must also be publicly-trusted. For example, the policy for hardenize.com must be
available for download at https://mta-sts.hardenize.com/.well-known/mta-sts.txt. The
policy is a plaintext file that contains a series of directives, one per line. Here's ours:
version: STSv1
mode: testing
mx: alt1.aspmx.l.google.com
mx: alt2.aspmx.l.google.com
mx: aspmx.l.google.com
mx: aspmx2.googlemail.com
mx: aspmx3.googlemail.com
max_age: 86400
Most of these directives are self-explanatory, especially if you already have experience with other
similar memory-based policies, such as HSTS. The mode parameter can be used to control policy
enforcement; the possible values are: enforce, testing, and none. For now, it's probably best to
leave your policy in testing mode, as we watch the support for this standard evolve. Apart from
that, you should obviously aim to add all your MX servers to the list. It's possible to use
wildcards, in the form of *.example.com, where * replaces one leftmost
label. (Warning: earlier MTA-STS drafts used a simplified wildcard syntax with only a dot at the
beginning; that approach is now deprecated).
As for the duration, start with a short value initially and increase it weekly and monthly as you gain confidence and nothing breaks. Per the RFC, values measured in weeks should be used for best protection against MITM attacks.
It's unusual that MTA-STS policies are delivered via HTTPS. A delivery mechanism based on an SMTP extension would feel more natural. Unfortunately, that approach would also require an upgrade of every single SMTP server installation out there, which is a monumental task.
The third and final step is to signal your support for MTA-STS and activate your policy via a
special DNS TXT record, using the _mta-sts hostname prefix. This is what our
configuration looks like when queried using dig:
_mta-sts.hardenize.com. 300 IN TXT "v=STSv1; id=aca9f86d663;"
Apart from indicating support for MTA-STS, the indicator is also used to publish a policy ID, which unique identifies a particular policy version. The ID can be a timestamp or simply a random number. Whenever your policy changes, the ID in the indicator must be updated also. This field is used for policy caching; if sending MTAs observe the same value as the one seen previously, they know they don't need to fetch your policy again and that saves them some time.
Once you're done tweaking your configuration, testing for correct deployment is easy, thanks to the fact that we've added an MTA-STS test to Hardenize. Just run our assessment against your domain name and head to the MTA-STS section to see the results. We will take care of checking that everything is configured correctly.
Without MTA-STS, we check for valid certificates installed on your mail servers, but we only issue warnings when there is a trust problem. That changes when MTA-STS is correctly enabled, and then we verify that your mail servers are allowed and require that they have publicly trusted certificates. You can see that in the email section of the report.
