Attacks on SMTP and MTA-STS downgrade

In this article, I audit several well-known email providers to find out how they handle email encryption and show how MTA-STS can help improve email security.

Anyone familiar with network security will see the problem here. An active attacker-in-the-middle (AitM) can substitute their own response, indicating that encryption is not supported, and trick the sender into using plain text, allowing the attacker to intercept messages. This is a classic downgrade attack.

Even when the receiving mail server presents a TLS certificate, there are plenty of problems. Let's consider the options available to the sending mail server when it is presented with a TLS certificate that it does not trust. The server's hostname may not match the one specified in the certificate, and the certificate may be expired or signed by an unknown certification authority (CA).

1. Send using the untrusted certificate

2. Downgrade to plaintext

3. Refuse to send the message.

Most mail senders choose the first option because it protects against passive AitM and ensures email delivery.

DANE and DNSSEC

The TLSA record proposed in DANE offers one possible improvement, which involves using signed DNS records.

Unfortunately, the implementation of DNSSEC is slow. Research shows that currently about 5% of domains use DNSSEC. Several major mail providers, such as Gmail, do not support DNSSEC. Therefore, we should consider other options.

MTA-STS

MTA-STS provides mail servers with a way to indicate that they will support encryption using a TLS certificate issued by a trusted certification authority (CA). The policy includes a max-age parameter that tells the sending mail server how long it should remember this policy.

I will not go into the details of how MTA-STS works, as it consists of several steps and is well described by other authors.

Creating an MTA-STS Auditor

I deployed a couple of Postfix mail servers and configured them with a catch-all email address and a mailbox_command that logs incoming messages to a database. Server A had a TLS certificate issued by Let’s Encrypt, a widely known public CA. On server B, TLS was completely disabled.

Both servers had an MTA-STS policy set to enforce.

These servers helped me determine the sender's policy by seeing which mail servers the sender's servers were sending email to. The sender cannot distinguish between intentionally misconfigured lack of TLS support on server B and an AitM attack. A sender that correctly implements MTA-STS should deliver mail to server A and refuse to use an unencrypted connection to server B.

Selected Mail Providers

For testing, I chose six mail providers. The first group is positioned as supporting MTA-STS:

• Gmail

• Outlook.com

• Proton Mail

• Tuta Mail

The second group includes several other well-known mail providers, although they do not claim to support MTA-STS:

• Fastmail

• Yahoo

Lazy caching of MTA-STS policies

At the very beginning of my testing, I sent an email from Gmail to my audit servers, but found that Google successfully delivered the message to both mail servers. Gmail supports MTA-STS, so this was surprising. After further investigation, I found that the problem was "lazy caching" mentioned in RFC 8461 §5.1:

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

As a result, when testing mailings, I started sending multiple messages. The first message filled the cache, and additional messages were processed using the cached policy.

This, unfortunately, means that the first message sent to the domain may still be vulnerable to downgrade attacks, but this is intentionally allowed in the RFC for performance reasons.

Transactional mail, password reset emails, and magic links

Using email for password reset or email confirmation has long been a standard solution. "Magic links" that allow you to log in directly to your account, bypassing passwords altogether, are also quite popular. But are these sensitive messages delivered without encryption?

These types of messages are often sent using transactional email providers, but I couldn't find a single such email provider that offered MTA-STS support. On the other hand, you can install and configure the same Postfix with the MTA-STS extension installed and send it yourself. Here are the hosted providers I tested:

• Amazon SES

• Mailgun

• SparkPost

Most transactional email providers support some combination of switches for different operating modes (enabling TLS and/or certificate verification). These switches are not always possible to turn on in practice, as some mail servers still do not support TLS, and many do not use valid certificates. Google reports that 2% of the emails they send are not encrypted, and it is unclear how many encrypted connections used trusted certificates. Requiring mandatory use of TLS and full certificate verification would block potential customers, so many websites avoid these settings for business reasons.

MTA-STS allows domains to choose TLS verification while allowing the sender to support mail servers with weaker security settings. It's the best of both worlds.

Research Results

For completeness, I also included a check of the incoming MTA-STS policy.

Here is what I found:

Surprisingly, Tuta Mail constantly sent the message to both mail servers. I don't see any requests coming to the MTA-STS policy server, so there is no indication that this feature has been implemented. Their marketing materials clearly mention MTA-STS support, and this feature is marked as completed in their issue tracking system, but it may only support incoming MTA-STS.

Otherwise, MTA-STS support matched the product documentation.

User Interface

What happens when you send an email and the message cannot be delivered due to MTA-STS?

If you receive a similar message, it will indicate a problem:

This timely feedback is crucial to help the user understand what happened to the email they sent.

Outlook notifies the user only of a complete message delivery failure after 24 hours. Awkwardly, this email contains a typo and does not mention that a TLS verification issue prevented delivery. Hopefully, the user interface will improve over time.

Try it yourself!

To help others conduct MTA-STS audits, I have open-sourced the project and am allowing anyone to use the already running audit tool (although I do not plan to maintain it in the long term).

It is built on Docker Compose and assumes DigitalOcean as the hosting provider. Substitute your own domain names and other settings where necessary. There are also four postfix servers that I did not mention, which help audit some other related issues - see the code for details.

While the audit infrastructure is online, you can generate test email addresses and view sender information (not content) for any received emails. Messages are logged, so do not expect privacy for messages you send here. To get started, run the audit.sh script:

$ ./audit.sh
Send an email to these addresses:
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],

Press any key to poll for messages, q to quit

...

{
"8a3ca551-d2d8-4f30-9661-c5dbe7b9c18d": [
    {
    "line": "Message Received:
             SENDER: [email protected] 
             ORIGINAL_RECIPIENT: [email protected]
             ...",
    "service": "postfix",
    "when": "2024-09-27T18:20:16Z"
    }
],
"c611ff0c-4920-444f-9e8d-6eef1d37f8a3": [
    {
    "line": "Message Received:
             SENDER: [email protected] 
             ORIGINAL_RECIPIENT: [email protected]
             ...",
    "service": "postfix",
    "when": "2024-09-27T18:20:16Z"
    }
]
}
Press any key to poll for messages, q to quit

Here you can see that Yahoo delivered email to both server A and server B.

Enable MTA-STS for Incoming Mail for Your Domain

If you receive email on your own domain, consider enabling MTA-STS. Wider adoption of MTA-STS will help encourage mail senders to add support. Contact your mail provider to find out what needs to be done. Here are links to the official documentation for the mail providers I have tested:

• Google

• Outlook.com

Protonmail does not claim to support MTA-STS for custom domains, but someone suggested a solution:

• Protonmail

The general process for enabling incoming MTA-STS is also well documented:

• Using Apache

• Using GitHub Pages

Fastmail and Yahoo use certificates from DigiCert, a trusted CA, so they could enable incoming MTA-STS without much effort.

When enabling MTA-STS, you should always configure TLSRPT, so don't forget to set it up as well.

Final Thoughts

MTA-STS provides a promising approach to increasing SMTP security. Unfortunately, the depth of adoption by major providers of this protocol is low.

The lack of MTA-STS support from hosted transactional email providers makes password reset emails from countless websites very vulnerable to SMTP downgrade and interception attacks. Customers should encourage transactional email providers to adopt MTA-STS.

Google provides the best user experience regarding messages that were delayed or not delivered due to MTA-STS. Quickly notifying the user of the issue and providing multiple updates was very helpful. Developers must consider how they communicate to their users about behavior caused by MTA-STS.

Additional Notes

HSTS is a similar technology that helps us protect websites. HSTS uses a preload list that allows web browsers to ship with a list of domain names known to support HSTS. SMTP used to use the STARTTLS policy list, but it was closed in favor of MTA-STS.

Like HSTS, the MTA-STS RFC does not specify which certificate authorities to use when verifying the certificate. The server, as promised, will use a certificate that the client (i.e., web browser or second mail server) will trust. This centralizes the decision of which CA to trust in the hands of popular web browsers (such as Chrome) and popular mail providers (such as Gmail). Web browsers quickly stopped supporting CAs after security incidents, so mail servers need to track which CAs senders trust and adjust settings as necessary.

With my test platform, I collect a lot of additional information:

• TLSRPT — aggregated reports from mail senders about undelivered messages.

• HTTP server logs showing requests for the MTA-STS policy file.

• Logs indicate that Proton Mail uses postfix-mta-sts-resolver, hinting that they use the Postfix stack.

• IPv6 support.

Future research can build on this foundation.

Finally, here is the TLSRPT report from Microsoft. It shows how I tried a couple of different configurations, but Microsoft correctly rejected the connection: