In short, MTA-STS is a way to further protect emails from eavesdropping (i.e. man-in-the-middle aka MitM attacks) as they travel between mail servers. It partially solves the legacy architectural problems of email protocols and is described in the relatively recent RFC 8461 standard. Mail.ru is the first major mail service on the Runet to implement this standard. And more details are already under the cut.
What problem does MTA-STS solve?
Historically, e-mail protocols (SMTP, POP3, IMAP) transmitted information in the clear, which allows it to be intercepted, for example, when accessing a communication channel.
What the mechanism for delivering a letter from one user to another looks like:
Historically, a MitM attack has been possible in all places where mail goes.
RFC 8314 requires the use of TLS between a user's mailer (MUA) and a mail server. If your server and mail applications are RFC 8314 compliant, then you have (largely) eliminated the possibility of Man-in-the-Middle attacks between the user and mail servers.
Compliance with generally accepted practices (standardized by RFC 8314) eliminates an attack near the user:
Mail.ru mail servers complied with RFC 8314 even before the adoption of the standard, in fact, it simply fixes already accepted practices, and we did not have to configure anything additionally. But, if your mail server still allows users using insecure protocols, be sure to implement the recommendations of this standard, because. most likely at least some of your users work with mail without encryption, even if you support it.
The mail client always works with the same mail server of the same organization. And you can force all users to connect securely, and then make it technically impossible to connect insecurely (this is exactly what RFC 8314 requires). It is sometimes difficult, but doable. With traffic between mail servers is still more difficult. The servers belong to different organizations and are often used in a "set it and forget it" mode, which makes it impossible to switch to a secure protocol at once without disrupting connectivity. SMTP has been providing the STARTTLS extension for a long time, allowing servers that support encryption to switch to TLS. But an attacker who has the ability to influence traffic can "cut out" information about the support of this command and force the servers to communicate using a plain text protocol (the so-called downgrade attack - an attack on downgrading the protocol version). For the same reason, STARTTLS usually doesn't check if the certificate matches (an untrusted certificate can protect against passive attacks, and this is no worse than sending a letter in clear text). Therefore, STARTTLS only protects against passive wiretapping.
MTA-STS partially eliminates the problem of intercepting messages between mail servers when an attacker has the ability to actively influence traffic. If the recipient's domain publishes an MTA-STS policy, and the sender's server supports MTA-STS, it will only send email over a TLS connection, only to the servers defined by the policy, and only with server certificate verification.
Why partially? MTA-STS only works if both parties have taken care to implement this standard, and MTA-STS does not protect against scenarios where an attacker has the ability to obtain a valid domain certificate from one of the public CAs.
How MTA-STS works
Recipient
- Configures STARTTLS support with a valid certificate on the mail server.
- Publishes the MTA-STS policy via HTTPS, using a special mta-sts domain and a special well-known path for publication, for example
https://mta-sts.mail.ru/.well-known/mta-sts.txt. The policy contains a list of mail servers (mx) authorized to receive mail for this domain. - Publishes a special _mta-sts TXT record in DNS with the policy version. When the policy is changed, this entry must be updated (this signals the sender to re-request the policy). For example,
_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"
Sender
The sender queries the _mta-sts DNS record, if present, makes a policy request over HTTPS (verifying the certificate). The resulting policy is cached (in case an attacker blocks access to it or changes the DNS record).
When sending mail, it checks that:
- the server to which mail is delivered is in the policy;
- the server accepts mail using TLS (STARTTLS) and has a valid certificate.
Benefits of MTA-STS
MTA-STS uses technologies that are already implemented in most organizations (SMTP+STARTTLS, HTTPS, DNS). For implementation on the side of the recipient, no special software support for the standard is required.
Disadvantages of MTA-STS
It is necessary to monitor the validity of the web and mail server certificate, name matching, and timely updating. Certificate issues will result in mail not being delivered.
On the sender side, an MTA with support for MTA-STS policies is required, currently out of the box MTA-STS is not supported in the MTA.
The MTA-STS uses a list of trusted root CAs.
MTA-STS does not protect against attacks in which the attacker uses a valid certificate. In most cases, MitM near the server implies the possibility of issuing a certificate. Such an attack can be detected through Certificate Transparency. Therefore, in general, MTA-STS mitigates but does not completely eliminate the possibility of traffic interception.
The last two points make the MTA-STS less secure than the competing DANE standard for SMTP (RFC 7672), but more technically secure; for MTA-STS, there is a low chance that the message will not be delivered due to technical problems caused by the implementation of the standard.
Competing standard - DANE
DANE uses DNSSEC to publish certificate information and does not require external CAs to be trusted, which is much more secure. But the use of DNSSEC leads to technical failures significantly more often, based on statistics over several years of use (although there is a positive trend in the reliability of DNSSEC and its technical support in general). To implement DANE in SMTP on the recipient side, the presence of DNSSEC for the DNS zone is mandatory, and for DANE, correct support for NSEC / NSEC3 is essential, with which DNSSEC has systemic problems.
If DNSSEC is configured incorrectly, this can result in mail delivery failures if the sending side supports DANE, even if the receiving side is unaware of it. Therefore, despite the fact that DANE is an older and more secure standard and is already supported in some server software on the sender side, in fact its penetration remains insignificant, many organizations are not ready to implement it due to the need to implement DNSSEC, this significantly slowed down the implementation of DANE all those years that the standard exists.
DANE and MTA-STS do not conflict with each other and can be used together.
What about MTA-STS support in Mail.ru Mail
Mail.ru has been publishing an MTA-STS policy for all major domains for quite some time now. Now we are implementing the client part of the standard. At the time of writing, the policies are applied in a non-blocking mode (in case the delivery is blocked by the policy, the letter will be delivered through the "backup" server without applying the policies), then the blocking mode will be forced for a small part of the outgoing SMTP traffic, gradually for 100% of the traffic will be policy enforcement is supported.
Who else maintains the standard
So far, MTA-STS policies publish about 0.05% of active domains, but, nevertheless, they already protect a large amount of mail traffic, because. the standard is supported by large players - Google, Comcast and partly Verizon (AOL, Yahoo). Many other postal services have announced that support for the standard will be implemented in the near future.
How will this affect me?
Not unless your domain publishes an MTA-STS policy. If you publish a policy, then messages for users of your mail server will be better protected from interception.
How do I implement MTA-STS?
Support for MTA-STS on the recipient side
It is enough to publish the policy via HTTPS and records in DNS, configure a valid certificate from one of the trusted CAs (you can Let's encrypt) for STARTTLS in the MTA (STARTTLS is supported in all modern MTAs), special support from the MTA is not required.
Step by step, it looks like this:
- Configure STARTTLS on the MTA you are using (postfix, exim, sendmail, Microsoft Exchange, etc.).
- Make sure you are using a valid certificate (issued by a trusted CA, not expired, the subject of the certificate matches the MX record that delivers mail for your domain).
- Configure a TLS-RPT entry for reporting policy enforcement (by services that support sending TLS reports). An example entry (for the example.com domain):
smtp._tls.example.com. 300 IN TXT Β«v=TLSRPTv1;rua=mailto:[email protected]Β»This entry instructs mail senders to send statistical reports on TLS usage in SMTP to
[email protected].Follow the reports for a few days, make sure there are no errors.
- Publish the MTA-STS policy over HTTPS. The policy is published as a text file with CRLF line terminators by location.
https://mta-sts.example.com/.well-known/mta-sts.txtPolicy example:
version: STSv1 mode: enforce mx: mxs.mail.ru mx: emx.mail.ru mx: mx2.corp.mail.ru max_age: 86400The version field contains the version of the policy (currently
STSv1), Mode sets the policy application mode, testing - test mode (the policy is not applied), enforce - "combat" mode. First, publish the policy with mode: testing, if there are no problems with the policy in test mode, after a while you can switch to mode: enforce.mx specifies a list of all mail servers that can accept mail for your domain (each server must have a certificate configured that matches the name specified in mx). Max_age sets the policy caching time (once a remembered policy will be applied even if an attacker blocks its return or corrupts DNS records during the caching time, you can signal the need to re-query the policy by changing the mta-sts DNS record).
- Publish a TXT record to DNS:
_mta-sts.example.com. TXT βv=STS1; id=someid;βAn arbitrary identifier (for example, a timestamp) can be used in the id field, it should change when the policy changes, this allows senders to understand that they need to re-request the cached policy (if the identifier differs from the cached one).
MTA-STS support on the sender side
So far, itβs bad with her, because. fresh standard.
- Exim - no built-in support, there is a third-party script
- Postfix - no built-in support, there is a third-party script, which is described in detail on HabrΓ©
As an afterword about "mandatory TLS"
Regulators have been paying attention to email security lately (and that's a good thing). For example, DMARC is mandatory for all government agencies in the United States and is increasingly required in the financial sector, in regulated areas, the penetration of the standard reaches 90%. Now some regulators require the implementation of "mandatory TLS" with separate domains, but at the same time, the mechanism for ensuring "mandatory TLS" is not defined and in practice this setting is often implemented in a way that does not even minimally protect against real attacks that are already provided for in such mechanisms as DANE or MTA-STS.
If the regulator requires "mandatory TLS" to be implemented with individual domains, we recommend that MTA-STS or a partial equivalent be considered as the most appropriate mechanism, it eliminates the need to make secure settings on a per-domain basis. If you have difficulties with the implementation of the client part of MTA-STS (until the protocol has received wide support, they most likely will), you can recommend this approach:
- Publish the MTA-STS policy and/or DANE records (DANE only makes sense if DNSSEC is already enabled for your domain, and MTA-STS anyway), this will protect traffic to your side and eliminate the need to ask other mail services to configure mandatory TLS for your domain if the mail service already supports MTA-STS and/or DANE.
- For large mail services, implement an βanalogueβ of MTA-STS through separate transport settings for each domain, which will fix the MX used for mail relaying and will require mandatory verification of the TLS certificate for it. If the domains are already publishing an MTA-STS policy, this can most likely be done painlessly. By itself, enabling mandatory TLS for a domain without fixing the relay and verifying the certificate for it is inefficient from a security point of view and does not add anything to the existing STARTTLS mechanisms.
Source: habr.com