{"id":417024,"date":"2024-06-30T01:18:31","date_gmt":"2024-06-30T01:18:31","guid":{"rendered":"http:\/\/savepearlharbor.com\/?p=417024"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-29T21:00:00","slug":"","status":"publish","type":"post","link":"https:\/\/savepearlharbor.com\/?p=417024","title":{"rendered":"Dive into Email Security: MTA-STS Policies<\/span>"},"content":{"rendered":"
<\/div>\n
\n
\n
\n
<\/p>\n

In a nutshell: MTA-STS is a way to protect emails against interception (man-in-the-middle aka MitM attacks) between email servers. It partially resolves architectural issues in email protocols and is described in a recent RFC 8461 standard.
<\/a> <\/p>\n

What is the issue MTA-STS resolves?<\/h2>\n

Historically, email protocols (SMTP, POP3, IMAP) transfer information in plaintext, making it possible to intercept, e.g. by accessing a communication link. This is how email delivery works:<\/p>\n

<\/p>\n

Historically, Man-in-the-Middle attack was possible everywhere.<\/p>\n

RFC 8314 standard requires using TLS between a mail user agent (MUA) and an email server. If your server and MUA match to RFC 8314, this mostly means elimination of Man-in-the-Middle attacks between MUA and mail servers:<\/p>\n

<\/p>\n

Our Mail.ru email servers had already matched to RFC 8314 before the standard was adopted; it just reinforces best practices, so we had nothing to adjust. But if your email server still connects through unsecure protocols, you have to implement the standard. Because part of your users still has no encryption using email.<\/p>\n

The mail client always works with one and the same mail server. So we can force all users to connect securely and then make unsecure connections technically impossible (as specified by RFC 8314). Sometimes it is hard to do, but still possible. Things get more complicated when it comes to traffic between mail servers. Servers are owned by different organizations and are often used like \u00abinstall and forget\u00bb. So we can\u2019t quickly switch over to a secure protocol without loss of connectivity. STARTTLS extension, provided in SMTP, allows servers with encryption switch to TLS.<\/p>\n

However, the attacker can know about using STARTTLS and make servers communicate over standard text protocol (so-called downgrade attack). For the same reason, certificate validity is not usually verified for STARTTLS. So an untrusted certificate can protect from passive attacks, which is no worse than sending an mail in plaintext. Thus, STARTTLS protects only from passive traffic sniffing.<\/p>\n

MTA-STS partially resolves the mail interception issue between mail servers when the attacker can spoof traffic. If the recipient’s domain publishes MTA-STS policy, and the sender’s server supports MTA-STS, mail will be sent only through TLS connection. This applies only to servers specified by the policy, and only with the server’s certificate validation.<\/p>\n

Why partially? MTA-STS operates only when both parties have implemented this standard. MTA-STS does not protect if the attacker has obtained a valid domain certificate from a public CA.<\/p>\n

How MTA-STS works<\/h2>\n

Recipient<\/strong><\/p>\n

    \n
  1. Implements support for STARTTLS with a valid certificate.\u00a0<\/li>\n
  2. Publishes MTA-STS policy through HTTPS; special mta-sts domain and special well-known path are used, for example, https:\/\/mta-sts.mail.ru\/.well-known\/mta-sts.txt<\/code>. The policy contains a list of mail servers (mx) to receive mail for this domain.<\/li>\n
  3. Publishes special TXT record _mta-sts<\/code> in DNS with policy version. Whenever the policy is modified, this record should be updated (this prompts the sender to request it again). For example, _mta-sts.mail.ru. TXT \"v=STSv1; id=20200303T120000;\"<\/code><\/li>\n<\/ol>\n

    Sender<\/strong><\/p>\n

    The sender requests DNS record _mta-sts<\/code> and policy through HTTPS (verifying the certificate). The obtained policy is cached (for the case if an attacker blocks access to it or spoofs DNS record).<\/p>\n

    When mail is sent, it is verified that:<\/p>\n