When we send an email, we are not just looking for it to reach its destination. We also hope that our privacy is respected and that it reaches its destination maintaining its integrity, in such a way that it is not tampered with. What we want is that when we send an e-mail, it is encrypted, so that it cannot be read or manipulated by cybercriminals. One very important thing is that in the SMTP protocol, when we send an email, encryption is optional. This means that our e-mail can be sent in plain text, and to enforce security a relatively new standard has been created that is not another MTA-STS that we will talk about next.
We are going to start talking about the SMTP protocol, its origin, why we need it to be encrypted and what the new MTA-STS protocol can offer us.
Evolution of SMTP over time
The SMTP protocol comes from the English Simple Mail Transfer Protocol whose translation we can call it as a protocol for simple mail transfer . As for its origin, it dates back to 1982, and it is the mail protocol that we use to send emails between different computers, mobile devices such as smartphones, etc.
Over time, SMTP has evolved and improved its security. Thus STARTTLS was born, which is a protocol that was added to STMP, whose function is to allow an email server to tell another that it wants to send an email through an encrypted communication channel. In this way, we can convert a non-secure connection into a secure one that is encrypted, using the TLS protocol. Here you have a simple outline of how SMTP works in service providers.
Today the STARTTLS protocol is widely used to provide confidentiality in authentication with the mail server. Furthermore, when using this protocol, the TCP ports involved in the communication are different. For example, SMTP uses TCP port 25, but if we use SMTPS (with STARTTLS) the port is 465 by default.
MTA-STS and SMTP TLS Reporting (TLS-RPT) to improve security
A very important problem we have with SMTP is that emails can be sent in plain text because encryption is optional.
To improve the situation, a new mechanism called Mail Transfer Agent-Strict Transport Security, whose acronym is MTA-STS, was created. This fairly recent standard allows mail service providers to enforce transport layer security with TLS encryption to protect SMTP connections. In addition, it also allows you to specify whether sending SMTP servers should deny delivery of messages to MX hosts that do not offer TLS with a trusted server certificate. The benefit is that it has been shown to successfully mitigate TLS degradation attacks and Man-in-the-Middle (MitM) attacks.
Another element that helps improve security is the SMTP TLS Reporting standard (TLS-RPT) and it is documented in RFC 8460 that was published in September 2018. Thanks to it, it will allow us to report TLS connectivity problems experienced by applications. who send email . Thus, it will allow us to notify when there are problems with the delivery of an email because it is not encrypted with TLS.
Why we need to send encrypted emails
The goal is simple: we want our email to reach its recipients without anyone having read or manipulated it. Thus, the main reason is to improve transport-level security during SMTP communication, in order to guarantee the privacy of email traffic. In this sense, the encryption of incoming messages addressed to us also improves information security, since cryptography is used to safeguard electronic information. For this reason, both the sender and the receiver are benefiting from this security enhancement. Another important issue is that Man-in-the-Middle (MitM) attacks, such as SMTP Downgrade and DNS spoofing attacks are becoming more frequent.
MitM attacks and DNS spoofing
A Man-in-the-Middle attack or MitM attack is one in which the attacker acquires the ability to read, insert and modify communications at will. In this way, your job will consist of being able to observe and intercept messages between the two users, and then ensure that neither of the two victims knows that the link has been violated.
As we have already commented previously, to implement encryption in the SMTP protocol we must use the STARTTLS command. The MITM attacker can take advantage of this situation by performing an SMTP downgrade attack on the SMTP connection. What the cybercriminal does is alter the command, replace it or delete it. So what happens is that it forces the client to resend that email in plain text.
Another way they could attack is through a DNS spoofing attack. A very important detail that you should know is that DNS is an unencrypted system. In this way, a cybercriminal would act by replacing the MX records in the response to the DNS query with a mail server that they have access to and are under their control. Then it would easily divert DNS traffic flowing through the network.
What would happen next is that our email provider would deliver our email to the attacker’s server. At that point, the cybercriminal can access and manipulate that message. That email will then be forwarded to the intended recipient’s server afterwards, without being detected.
Always get TLS encryption with MTA-STS
At the time we implement MTA-STS, the MX addresses are obtained through DNS and compared to those found in the MTA-STS policy file, which is sent over a secure HTTPS connection, which will mitigate DNS spoofing attacks. Therefore, if we do not send our emails through a secure connection, they run the risk of being intercepted or manipulated. To solve this problem, we have MTA-STS that successfully mitigates cryptographic attacks and improves the security of our information by using TLS encryption.
In summary, MTA-STS offers us:
- Encrypted email transfer over TLS.
- If an encrypted connection cannot be established, the email is not delivered. This does not send clear text.
- MTA-STS policies securely serve MX addresses making DNS spoofing attack difficult.
In addition, MTA-STS offers us protection against degradation attacks, DNS spoofing and MitM, solves various SMTP security problems such as expired TLS certificates.
The importance of enabling TLS-RPT
Thanks to TLS-RPT , domain owners can get diagnostic reports in JSON file format on emails addressed to their domain. That way, they can find out if they are facing delivery issues related to a downgrade or other attack. If we enable TLS-RPT we obtain these benefits:
- You will be notified if an email does not reach your domain due to a delivery problem.
- Provides detailed diagnostic reports that allow us to identify the email delivery problem so that it can be resolved as soon as possible.
Adoption of MTA-STS and TLS-RPT is already underway
Major email service providers like Microsoft and Google already support it. Google was one of the first to adopt this protocol. The adoption of MTA-STS by Google and other large companies indicates their interest in having secure protocols to encrypt e-mail in transit.
Therefore, the best way to guarantee the security of our emails, today, is to use the MTA-STS protocol together with TLS-RPT to inform us when a failure is occurring.
