SMTP downgrade attacks and MTA-STS

When SMTP was created it was cleartext only, as we hadn't yet figured out Transport Layer Security (TLS). When TLS was finally ready, we needed a way to phase TLS in. STARTTLS was created and offered opportunistic encryption. Basically, a mail sender could ask the destination mail server: 'Do you support encryption?' If the reply was positive, then a TLS session would be established using the certificate the server provided. If not, then a cleartext SMTP session would be used (Figure 1).

Anyone who's studied network security will see a problem here. An active Attacker-in-the-Middle (AitM) can inject their own response, claiming that encryption isn't supported and tricking the sender into using cleartext, and allowing the attacker to eavesdrop on the message (Figure 2). This is a classic downgrade attack.

Even when the receiving mail server presents a TLS certificate, troubles abound. Consider the options a sending mail server has when it is presented with a TLS certificate it doesn't trust. Maybe the hostname doesn't match, it's expired, or it's signed by an unknown Certificate Authority (CA):

1. Send using the untrusted certificate
2. Downgrading to cleartext
3. Refuse to send the message

Most mail senders chose the first option as it protects against passive AitM and ensures email is delivered.

DANE and DNSSEC

DANE's TLSA record offers one possible improvement, which leverages signed DNS records.

Unfortunately, DNSSEC adoption has been slow. Measurement studies show that around 5% of domains currently use DNSSEC. Several large email providers like Gmail do not support DNSSEC. As such, other options are being considered.

MTA-STS

Mail Transfer Agent Strict Transport Security (MTA-STS) provides a way for mail servers to indicate that they will support encryption using a TLS certificate issued by a trusted CA. The policy includes a parameter that tells the sending mail server how long it should remember the policy (Figure 3).

I won't get into the full details of how MTA-STS works, as it involves several steps and is well documented elsewhere.

Building an MTA-STS auditor

I stood up a pair of Postfix mail servers and configured them with a catch-all email address and a mailbox_command that logs incoming messages to a database. As shown in Figure 4, server A has a TLS certificate issued by Let's Encrypt, a widely trusted public CA and server B has TLS fully disabled.

Both servers have an MTA-STS policy set to .

These servers help me infer the sender policy by allowing me to see which mail servers receive emails. The sender cannot distinguish B's intentionally misconfigured lack of TLS support from an AitM attack. A sender properly implementing MTA-STS should deliver mail to A and refuse to use an unencrypted connection with B.

Selected mail providers

I picked six mail providers for testing. The first group are marketed as supporting MTA-STS:

The second group includes other prominent mail providers, although these do not claim to support MTA-STS:

Lazy caching of MTA-STS policy

During early testing, I sent an email from Gmail to the audit servers but found that Google delivered the message to both mail servers. Gmail has MTA-STS support, so this was surprising. Upon further research, I found that lazy caching was the problem:

… fetch a new policy (perhaps asynchronously, so as not to block message delivery).

RFC 8461, section 5.1

When testing mail senders I needed to send multiple messages. The first would prime the cache and additional messages would be processed using the cached policy.

This unfortunately means the first message sent to a domain could still be vulnerable to downgrade attacks, but this is intentionally permitted by the RFC for performance reasons.

Transactional email, password reset, and magic links

Using email for password reset or email verification has long been an industry standard. Magic links that directly log you into an account, avoiding passwords altogether, are also fairly popular. But are those sensitive messages getting delivered without encryption?

These sorts of messages are often sent using transactional email providers, but I wasn't able to find any hosted providers that offered MTA-STS support. It is possible to self-host Postfix and use an MTA-STS extension to do it yourself. Here are the hosted providers I tested:

• Amazon SES
• Mailgun
• SparkPost

Most transactional email providers support some combination of toggles for enabling TLS and/or certificate verification. These sorts of toggles are difficult to enable, in practice, as some mail servers still don't support TLS and many don't use valid certificates. Google reports that 2% of the emails they send aren't encrypted. It's unclear how many of the encrypted connections used trusted certificates. Requiring TLS and fully verifying certificates would block potential customers, so many websites avoid these settings for business reasons.

MTA-STS allows domains to opt-in to TLS verification while still allowing the sender to support mail servers with weaker security settings. This is the best of both worlds.

Results

I've also included a check for inbound MTA-STS policy, for completeness.

Here's what I found:

Surprisingly, Tuta Mail consistently sent the message to both mail servers. I don't see any requests reaching the MTA-STS policy server, so there's no indication that the feature has been implemented. Their marketing material clearly mentions MTA-STS support and the feature is marked as completed in their issue tracker, but perhaps only inbound MTA-STS is supported.

Otherwise, MTA-STS support matched product documentation.

User experience

What happens when you send an email and the message can't be delivered due to MTA-STS? You'll receive a message like Figures 6 to 8 indicating that there's a problem:

This timely feedback is critical for helping the user understand what happened to the email they sent.

Outlook only notifies the user when the message fully fails, after 24 hours (Figure 9). Awkwardly, this email contains a typo and doesn't mention that a TLS verification issue prevented delivery. Hopefully, the user experience will improve over time.

Try it yourself

To help others audit MTA-STS, I'm open sourcing the project code and allowing others to use the hosted audit tool (although I don't plan to keep it online long-term).

It uses Docker Compose and assumes DigitalOcean as the hosting provider. Substitute your own domain names and other settings where needed. There are four other postfix servers I haven't mentioned, which help audit some other related concerns. Check the code for full details.

While the audit infrastructure is online you can generate test email addresses and see sender information (not content) for any received email. Messages are being logged, so don't expect any privacy for messages you send here. Run the audit.sh tool to get started:

This shows that Yahoo delivered email to both the A and the B server.

Enable inbound MTA-STS for your domain

If you receive email on your own domain, consider enabling MTA-STS. Increased adoption of MTA-STS will help encourage mail senders to add support. Check with your email provider to learn how you can get started. Here's the official documentation for the mail providers I've tested:

Protonmail doesn't claim to support MTA-STS for custom domains, but others have offered solutions:

The general process for enabling inbound MTA-STS is well documented too:

Fastmail and Yahoo use certificates from DigiCert, a trusted CA, so they can enable inbound MTA-STS without much work.

You should always set up Transport Layer Security Reporting (TLS-RPT) when enabling MTA-STS, so be sure to enable that as well.

Closing thoughts

MTA-STS provides a promising approach to strengthening SMTP security. Unfortunately, adoption by major providers is low.

The lack of MTA-STS support by hosted transactional email providers exposes the password reset emails of countless websites vulnerable to downgrade attacks and snooping. Everyone should encourage transactional email providers to adopt MTA-STS.

Google provides the best user experience for messages that have been delayed or failed due to MTA-STS. Notifying the user about the problem quickly, and providing several updates was very helpful. Implementers should be sure to consider how they communicate MTA-STS-induced behaviours to their users.

Robert Alexander (Mastodon) is a freelance software developer and security consultant interested in software, the cloud, and security.

Adapted from the original post on Robert's blog.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Public link

Please use the above public link if you want to share this noodl on another website.