SMTP and MTA-STS downgrade attacks

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

When SMTP was created, it worked by transmitting data in the clear because we had not yet developed a solution for secure data transmission, what we now call “transport layer security” (TLS). Once TLS was finally ready, we needed to figure out a way to implement TLS in stages. STARTTLS was created to offer “where possible” encryption. Essentially, the sender's mail server could ask the recipient's mail server, “Do you support encryption?” and, if the answer was yes, a TLS connection would be established using a certificate provided by the server. If not, a cleartext SMTP connection was used.

Anyone familiar with the topic of network security will see a problem here. An active attacker carrying out an attacker-in-the-middle (AitM) attack could substitute his own response to indicate that encryption is not supported and trick the sender into using plaintext, allowing the attacker to intercept messages. This is a classic downgrade attack.

Even when the receiving mail server presents a TLS certificate, problems abound. Let's look at the options that the sending mail server has when it is presented with a TLS certificate that it doesn't trust. The server's hostname may not match what is listed on the certificate, and the certificate may be expired or signed by an unknown certificate authority (CA).

1. Send using an untrusted certificate

2. Downgrade to plaintext version

3. Refuse to send the message.

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

DANE and DNSSEC

DANE's proposed TLSA record offers one possible improvement by using signed DNS records.

Unfortunately, adoption of DNSSEC has been slow. Research shows that about 5% of domains currently use DNSSEC. Several major email providers, such as Gmail, do not support DNSSEC. Thus, we should consider other options.

MTA-STS

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

I won't go into detail about how MTA-STS works, since 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 mail address and mailbox_commandwhich writes logs of incoming messages to the database. Server A had a TLS certificate issued by Let's Encrypt, a well-known public CA. On the server B TLS was completely disabled.

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

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

Selected email providers

I chose six email providers for testing. The first group is positioned as supporting MTA-STS:

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

Lazy caching MTA-STS policies

Early in my testing, I sent an email from Gmail to my audit servers, but found that Google was successfully delivering the message to both mail servers. Gmail supports MTA-STS, so this was surprising. After further investigation, I discovered that the problem was “lazy caching” mentioned in RFC 8461 §5.1:

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

As a result, when testing mailings, I began to send several 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 to reset your password or verify your email has long been a standard solution. “Magic links” that allow you to directly log into an account, avoiding 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 any such email provider that offers MTA-STS support. On the other hand, you can independently install and configure the same Postfix with installed MTA-STS extensionand handle the shipping yourself. Here are the hosted providers I tested:

• Amazon SES

• Mailgun

• SparkPost

Most transactional email providers support some combination of modes of operation (enable TLS and/or certificate verification). In practice, it is not always possible to set these switches to the on position, since some mail servers still do not support TLS, and many do not use valid certificates. Google reportsthat 2% of the emails they send are not encrypted, and it is unclear how many encrypted connections used trusted certificates. Requiring TLS and full certificate validation would block potential clients, so many websites avoid these settings for business reasons.

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

Research results

For completeness, I've also included MTA-STS inbound policy checking.

Here's what I found:

Surprisingly, Tuta Mail was constantly sending the message to both mail servers. I don't see any requests coming into 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 the feature is marked as complete in their issue tracker, but it may be that only inbound MTA-STS is supported.

Otherwise, MTA-STS support was consistent with 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 message like this, it will indicate a problem:

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

Outlook notifies the user only after a complete failure to send a message, after 24 hours. It's embarrassing that 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 have opened project source code and let everyone use the already running audit tool (although I don't plan to keep it running in the long term).

It is built on Docker Compose and uses DigitalOcean as the hosting provider. Substitute your own domain names and other settings where needed. There are four more postfix servers that I haven't mentioned that help audit some other related issues – see the code for details.

As long as the auditing infrastructure is online, you can generate test email addresses and view sender information (not content) for any email received. Messages are logged, so have no expectation of privacy for messages you post here. To get started, run the script audit.sh:

$ ./audit.sh
Send an email to these addresses:
8a3ca551-d2d8-4f30-9661-c5dbe7b9c18d@a.audit.alexsci.com,
c611ff0c-4920-444f-9e8d-6eef1d37f8a3@b.audit.alexsci.com,
55c358c8-e979-4454-b14e-b8f10454e37b@c.audit.alexsci.com,
a10c2853-40f5-4c6d-8f85-7ab38038f84e@d.audit.alexsci.com,
b0d70539-2021-4194-adf1-d2585a162c34@e.audit.alexsci.com,
c77b3caa-bdc7-4160-b24a-2d9646785035@f.audit.alexsci.com,

Press any key to poll for messages, q to quit

...

{
"8a3ca551-d2d8-4f30-9661-c5dbe7b9c18d": [
    {
    "line": "Message Received:
             SENDER: mtastsaudit@yahoo.com 
             ORIGINAL_RECIPIENT: 8a3ca551-d2d8-4f30-9661-c5dbe7b9c18d@a.audit.alexsci.com
             ...",
    "service": "postfix",
    "when": "2024-09-27T18:20:16Z"
    }
],
"c611ff0c-4920-444f-9e8d-6eef1d37f8a3": [
    {
    "line": "Message Received:
             SENDER: mtastsaudit@yahoo.com 
             ORIGINAL_RECIPIENT: c611ff0c-4920-444f-9e8d-6eef1d37f8a3@b.audit.alexsci.com
             ...",
    "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 the email to both Server A and Server B.

Enable MTA-STS on entry 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 email provider to find out what you need to do to do this. Here are links to the official documentation for the email providers I tested:

Protonmail doesn't claim support for MTA-STS for custom domains, but someone suggested a solution:

General activation process incoming MTA-STS is also well documented:

Fastmail and Yahoo use certificates from DigiCert, a trusted CA, so they might want to include incoming MTA-STS without much effort.

TLSRPT should always be configured when enabling MTA-STS, so be sure to configure that as well.

Final Thoughts

MTA-STS provides a promising approach to increasing SMTP security. Unfortunately, the depth of implementation of this protocol by the main providers is small.

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

Google provides the best possible user experience for messages that are delayed or undeliverable due to MTA-STS. Notifying the user quickly about the issue and providing multiple updates was very helpful. Developers should be sure to consider how they communicate behavior caused by MTA-STS to their users.

Additional Notes

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

Like HSTS, the MTA-STS RFC does not specify which certificate authorities should be used when validating a certificate. The server is promised to use a certificate that the client (ie the web browser or second mail server) will trust. This centralizes the decision about which CAs to trust in the hands of popular web browsers (like Chrome) and popular email providers (like Gmail). Web browsers quickly stopped supporting CAs after security incidents occurred, so mail servers need to monitor which CAs senders trust and adjust settings if necessary.

Using my testing platform I collect a lot of additional information:

• TLSRPT – Aggregated reports from mail senders about undelivered messages.

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

• Logs indicate that Proton Mail uses postfix-mta-sts-resolverhinting that they are using the Postfix stack.

• IPv6 support.

Future research could build on this foundation.

Finally, here is the TLSRPT report from Microsoft. Here you can see how I tried a couple of different configurations, but Microsoft correctly rejected the connection: