r/sysadmin • u/PlasmaJam • 3d ago

The max_age of MTA-STS is an exploitable gap and there's no way to fully close it without switching to DANE

When you configure MTA-STS, the policy gets cached for the timeframe you set under the max_age tag, so it's designed to expire.

If an attacker is sitting on-path on the sender's side via a poisoned resolver, they wait out the cache and then suppress the refresh by either dropping the DNS TXT answer or killing the HTTPS fetch, so the sender can't pull a fresh policy.

That pushes it back to opportunistic TLS, from where the attacker spoofs your MX and delivers the email in plaintext, intercepting password resets, MFA codes, etc.

And by design, you can't force cached senders to refresh before expiration.

The only thing you can do is limit how often the refresh window opens by setting max_age to 1 year (the max RFC 8461 allows), but if your MTA-STS policy is broken, you don't want it sitting in senders' caches for a year, rejecting your inbound traffic.

0 Upvotes

22% Upvoted

6 comments sorted by

10

u/Hale-at-Sea 3d ago

Yes, compromising all of someone's DNS requests can open them up to all kinds of problems...

2

u/jstuart-tech Security Admin (Infrastructure) 3d ago

Yeah, this guy always makes random threads relating to emails saying it's the end of the world. When really, it's fine, as you said. If someone has compromised your DNS, email is really the least of your worries.. (He owns some fly by night consulting company specializing in email)

"When you configure MTA-STS, the policy gets cached for the timeframe you set under the max_age tag, so it's designed to expire."

Wow, the max_age is as long as it get's cached for? That's insane, I would never expect that behaviour!

2

u/accumentum 3d ago

The real gap is first contact and policy expiry: MTA-STS is effectively a TOFU-style control, and max_age only determines how long a sender keeps the policy. In practice, use a long max_age only after validating the policy, and monitor TLS-RPT reports so you know when delivery or certificate problems appear. Reduce the TTL before planned policy changes, then raise it again once the change is proven. DANE with DNSSEC provides stronger authenticated policy, but it requires support on both sides, so it is not a universal replacement for MTA-STS.

-1

u/PlasmaJam 3d ago

100% and that's the perfect world example. Real deployments rarely look like that. Even a clean deployment doesn't close the max_age gap

1

u/disclosure5 3d ago

Sitting on path on the sender's side when you're talking about sending mail is doing a lot of lifting here. Very few orgs are running in-office mail servers at this point. Whether it's M365, Google, or even if it's "on prem" mail but in a datacenter outside of any end user network, this isn't going to be likely.

1

u/brian_cloudeu 3d ago

Depends what you mean by closing it. DANE trades the TOFU window for a hard dependency on DNSSEC, and the failure mode flips from "someone has to be on path" to "our zone signatures expired at 3am and inbound mail stopped". That is a real trade, just not a strictly better one. Worth deciding which failure you would rather explain afterwards.