SMTP Downgrade Attacks and MTA-STS(alexsci.com)
alexsci.com
SMTP Downgrade Attacks and MTA-STS
https://alexsci.com/blog/smtp-downgrade-attacks-and-mta-sts/
16 comments
Storing public keys is the easy part of the problem. It's the rest of the PKI that's hard. People on message boards tend to want a simple replacement for the WebPKI that they can, ideally, host themselves. But without some Internet-wide root of trust, with some story for handling "bad" keys, and some story for transparency, any such system is going to have materially less security than the WebPKI. The WebPKI is free and well-supported today. So it's reasonable for operators to look for solutions that build on it, rather than trying to replace it.
DNS is trusted by definition. It is the "Internet-wide root of trust" because it names things.
What it doesn't do, DNSSEC tried to fix (chain of trust, negative acknowledgements, etc) but for some reason, it was considered "too hard", in the same way that IPv6 was/is.
It also didn't solve the security of the protocol because the queries remained unencrypted, even if the data returned was guaranteed to be accurate.
However, the result is things like DNS-over-https which essentially requires edge users to trust closer-to-the-center resolvers to maintain the security of their queries.
So we need a trusted, encrypted protocol to query a trusted, secured, distributed naming service.
Using https to a well-known source that relies on DNS for location adds very little to the security against poisoning a DNS cache.
So "storing public keys" isn't the easy part of the problem. The PKI should be in-built with the naming service because the names are what the PKI is protecting, as well as communications between them.
Which is back to where we started, that DNSSEC was the right idea with the wrong solution, so we're stuck with a hack.
What it doesn't do, DNSSEC tried to fix (chain of trust, negative acknowledgements, etc) but for some reason, it was considered "too hard", in the same way that IPv6 was/is.
It also didn't solve the security of the protocol because the queries remained unencrypted, even if the data returned was guaranteed to be accurate.
However, the result is things like DNS-over-https which essentially requires edge users to trust closer-to-the-center resolvers to maintain the security of their queries.
So we need a trusted, encrypted protocol to query a trusted, secured, distributed naming service.
Using https to a well-known source that relies on DNS for location adds very little to the security against poisoning a DNS cache.
So "storing public keys" isn't the easy part of the problem. The PKI should be in-built with the naming service because the names are what the PKI is protecting, as well as communications between them.
Which is back to where we started, that DNSSEC was the right idea with the wrong solution, so we're stuck with a hack.
I'm on IPv6 right now, and not because I went out of my way to be. IPv6 rollout wasn't slow because it was too hard; it was because it wasn't especially valuable. That's changed, and will continue to change. I agree that DNSSEC isn't good! But my point was that storing public keys isn't the hard part, and DNSSEC doesn't do a good job with the hard parts either.
Regarding where the PKI "should" be, it's good to want things!
Regarding where the PKI "should" be, it's good to want things!
> Using https to a well-known source that relies on DNS for location adds very little to the security against poisoning a DNS cache.
I think this analysis doesn't factor in the MTA-STS cache. While an attacker could block the MTA-STS records with a DNS cache poisoning attack, they'd need to perform the attack persistently to prevent the policy from being cached. This greatly reduces the window of vulnerability and complicates the attack.
I think this analysis doesn't factor in the MTA-STS cache. While an attacker could block the MTA-STS records with a DNS cache poisoning attack, they'd need to perform the attack persistently to prevent the policy from being cached. This greatly reduces the window of vulnerability and complicates the attack.
Sure, but it's security by obscurity and relying an the receiving and sending servers to maintain that cache long enough at both ends.
The problem is that the DNS contains an MX record that says where to deliver email for a domain. So when a sending server wants to send, it looks that up. Then it looks up the received name as an A/AAAA record to find the IP address to connect to.
So we're already relying on DNS, which can be poisoned.
The "fix" for DNS poisoning is not DNS-over-TLS/HTTPS because that basic problem isn't solved.
If we secure DNS against tampering/poisoning, then the same infrastructure can deliver public keys and other information safely as well.
The problem is that the DNS contains an MX record that says where to deliver email for a domain. So when a sending server wants to send, it looks that up. Then it looks up the received name as an A/AAAA record to find the IP address to connect to.
So we're already relying on DNS, which can be poisoned.
The "fix" for DNS poisoning is not DNS-over-TLS/HTTPS because that basic problem isn't solved.
If we secure DNS against tampering/poisoning, then the same infrastructure can deliver public keys and other information safely as well.
Is maintaining a cache difficult? Disk space is cheap and databases are reliable in 2024.
I'll mention that the MTA-STS policy includes a list of permitted MX, so a poisoned MX record would be detected. But you are still correct about "first email to a domain" concerns; MTA-STS does not offer protection when the policy isn't in the cache.
There's some obvious improvements we could consider, like a community list of domains known to support MTA-STS, and mail servers pre-warming their caches. That gets us something closer to the HSTS preload list, which protects the first connection to a domain. MTA-STS is a reasonable foundation for future work.
It's also really worth remembering that the current best practices for email are unencrypted connections, skipping TLS cert verification, and sometimes DANE. A solution that protects all but the first email is a big step forward.
I'll mention that the MTA-STS policy includes a list of permitted MX, so a poisoned MX record would be detected. But you are still correct about "first email to a domain" concerns; MTA-STS does not offer protection when the policy isn't in the cache.
There's some obvious improvements we could consider, like a community list of domains known to support MTA-STS, and mail servers pre-warming their caches. That gets us something closer to the HSTS preload list, which protects the first connection to a domain. MTA-STS is a reasonable foundation for future work.
It's also really worth remembering that the current best practices for email are unencrypted connections, skipping TLS cert verification, and sometimes DANE. A solution that protects all but the first email is a big step forward.
I was told on the MTA-STS working group list that well-known URIs were chosen because the working group did not think email server administrators were smart enough to use DNSSEC.
I also asked why this is better than just standardizing on a port and using SMTP over TLS with existing certificate infrastructure, but they did not answer that question.
I also asked why this is better than just standardizing on a port and using SMTP over TLS with existing certificate infrastructure, but they did not answer that question.
Blog author here, great question. I think HTTPS was chosen because, as an industry, we have exceptional knowledge of how to securely serve static web content. Some folks are using GitHub Pages for their mta-sts subdomain, for example. It's quite painless to set up and easy to reason about the security it provides.
Using TLS provided by the mail server may have been possible, similar to how the HSTS header is sent over the HTTPS connection. But unfortunately the MTA-STS policy if for the receiving domain (@example.com) and the receiving mail server may be run on a completely different domain. We need a signal that cryptographicly relates to the receiving domain.
Using TLS provided by the mail server may have been possible, similar to how the HSTS header is sent over the HTTPS connection. But unfortunately the MTA-STS policy if for the receiving domain (@example.com) and the receiving mail server may be run on a completely different domain. We need a signal that cryptographicly relates to the receiving domain.
Defaulting to SSL only is the easiest way. I'm surprised the industry has not moved on yet ... my mail server enforces SSL only.
Even if you enforce SSL-only on inbound mail, you're still vulnerable to the downgrade attack (or rather: the "prevent upgrade to TLS attack") - someone can MITM, and the sender will be speaking non-SSL to the MITMer, who'll speak SSL to you. To you things would look fine.
Enter MTA-STS, with which the sending mail server can deduce that no, things are not OK.
Or are you saying you're not doing STARTLS at all and servers delivering mail to you have to do an SSL handshake before getting to speak SMTP to you? I'm quite surprised if that's compatible with the wider SMTP world.
Or are you saying you're not doing STARTLS at all and servers delivering mail to you have to do an SSL handshake before getting to speak SMTP to you? I'm quite surprised if that's compatible with the wider SMTP world.
MTA-STS is still vulnerable to MITM. If someone can tamper with DNS queries, it's useless. It's also apparently useless for the first message because the policy will not be in cache and only fetched afterwards.
We could have added a field so that when a server announces that they support STARTTLS, they can say that this fact should be cached for X days.
We could have added a field so that when a server announces that they support STARTTLS, they can say that this fact should be cached for X days.
250-AUTH LOGIN PLAIN
250-STARTTLS
250-STARTTLS-CACHE-90-DAYSThe vulnerability of the first message is a real concern, MTA-STS is not perfect. But it looks like the easiest to deploy tool that can strengthen security for a very large number of messages.
One challenge for your suggestion is that the mail server is often run by a different organization, on a different domain from the receiving address. The HTTPS web server, on the other hand, has a TLS certificate for the mta-sts subdomain of the receiving address. This gives confidence that the MTA-STS policy is set by the receiving domain, not the receiving mail server.
One challenge for your suggestion is that the mail server is often run by a different organization, on a different domain from the receiving address. The HTTPS web server, on the other hand, has a TLS certificate for the mta-sts subdomain of the receiving address. This gives confidence that the MTA-STS policy is set by the receiving domain, not the receiving mail server.
That's a hard choice. Google reports that 2% of the email they send goes out unencrypted, it's too large a percent to ignore. If you are using Postfix, would you mind sharing which setting you use? They all have challenges.
Is there a recommended setting for Postfix users based on this article?
Blog author here. There's two parts to get it working on Postfix:
To enable MTA-STS for inbound email: Add DNS entries for the MTA-STS record and mta-sts.<domain>. Run a web server that serves the mta-sts.txt file (or use static hosting, like GitHub pages/Netlify/AWS S3/etc). Set up HTTPS on the web server. The repo in the post shows an NGINX approach with Let's Encrypt.
To enable MTA-STS for outbound email: you'll need to configure https://github.com/Snawoot/postfix-mta-sts-resolver. Be sure to read through the DANE related challenges in the README as there are some tradeoffs.
To enable MTA-STS for inbound email: Add DNS entries for the MTA-STS record and mta-sts.<domain>. Run a web server that serves the mta-sts.txt file (or use static hosting, like GitHub pages/Netlify/AWS S3/etc). Set up HTTPS on the web server. The repo in the post shows an NGINX approach with Let's Encrypt.
To enable MTA-STS for outbound email: you'll need to configure https://github.com/Snawoot/postfix-mta-sts-resolver. Be sure to read through the DANE related challenges in the README as there are some tradeoffs.
Is there no alternatives to DNSSEC that would have allowed the equivalent of DANE to be provided somehow?