We’re going to start talking about the SMTP protocol, its origins, why it is needed for encryption, and what the new MTA-STS protocol has to offer us.
The evolution of SMTP over time
SMTP protocol comes from english Simple Mail Transfer Protocol whose translation can we name protocol for simple mail forwarding … As for its origin, it dates back to 1982 and it is the postal protocol that we use to send emails between different computers, mobile devices such as smartphones, etc.
Over time, SMTP has evolved and increased its security. So STARTTLS was born, which is a protocol added to STMP whose function is to let a mail server tell another that it wants to send an email over an encrypted communication channel. Thus, we can transform an unsecured connection into a secure one, encrypted using the TLS protocol. Here you have a simple diagram of how SMTP works for service providers.
Today, the STARTTLS protocol is widely used to provide confidentiality when authenticating to a mail server. In addition, when using this protocol, the TCP ports involved in the exchange of data are different. For example, SMTP uses TCP port 25, but if we use SMTPS (with STARTTLS), it defaults to port 465.
MTA-STS and SMTP TLS Reporting (TLS-RPT) for increased security
A very important issue we face with SMTP is that emails can be sent in plain text since encryption is optional.
To improve the situation, a new mechanism has appeared called Mail Forwarding Agent – Strict Transport Security, whose acronym MTA-STS was created. This relatively recent standard allows postal service providers to provide transport layer security using TLS encryption to secure 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 advantage is that it successfully prevents TLS degradation attacks and Man-in-the-Middle (MitM) attacks.
Another element that helps to improve safety is SMTP TLS Reporting Standard (TLS-RPT) and this is documented in RFC 8460 which was published in September 2018. Thanks to it, we will be able to report TLS connection problems that applications are experiencing. who is sending the email … Thus, it will allow us to notify about problems with the delivery of the email, as it is not encrypted using TLS.
Why do we need to send encrypted emails
The goal is simple: we want our email to reach recipients without anyone reading it or manipulating it. Thus, the main reason is to improve transport layer security during SMTP communication to ensure the confidentiality of mail traffic. In this sense, encrypting incoming messages addressed to us also improves information security, since cryptography is used to protect electronic information. For this reason, both the sender and the recipient benefit from this security enhancement. Another major 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 An attack is an attack in which an attacker is able to read, insert, and modify messages at will. Thus, your job will be to be able to observe and intercept messages between two users, and then ensure that neither of the two victims knows that the link has been broken.
As we commented earlier, in order to implement encryption in the SMTP protocol, we must use the STARTTLS command. An MITM attacker could take advantage of this situation by executing SMTP Downgrade Attack over SMTP connection. The cybercriminal modifies the command, replaces it, or deletes it. So what happens is that it forces the client to resend that email in plain text.
Another way they can attack is DNS spoofing attack. A very important detail that you should know is that DNS is an unencrypted system. Thus, an attacker 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 will easily redirect DNS traffic going through the network.
What happens next is that our email provider will deliver our email to the attacker’s server. At this point, a cybercriminal can access and manipulate this message. This email will then be forwarded to the intended recipient’s server without being detected.
Always get TLS encryption with MTA-STS
At the time we implement MTA-STS, MX addresses are obtained through DNS and compared to the addresses found in the MTA-STS policy file, which is forwarded over a secure HTTPS connection, reducing the risk of DNS spoofing attacks. Therefore, if we do not send our emails over a secure connection, they run the risk of being intercepted or manipulated. To solve this problem, we have an MTA-STS that successfully prevents cryptographic attacks and improves the security of our information using TLS encryption.
Thus, MTA-STS offers us:
- Transmission of encrypted email over TLS.
- If an encrypted connection cannot be established, the email is not delivered. It does not send clear text.
- MTA-STS policies maintain MX addresses securely, making DNS spoofing attacks difficult.
In addition, MTA-STS offers us protection against degradation attacks, DNS spoofing and MitM, and solves various SMTP security issues such as expired TLS certificates.
The importance of providing TLS-RPT
Thanks to TLS-RPT , domain owners can receive diagnostic reports in JSON format via email addressed to their domain. That way, they can know if they are facing delivery issues related to a downgrade or another attack. If we enable TLS-RPT, we get the following benefits:
- You will receive a notification if an email is not delivered to your domain due to a delivery issue.
- Provides detailed diagnostic reports that allow us to identify an email delivery problem so that it can be resolved as soon as possible.
Implementation of MTA-STS and TLS-RPT has already begun
Major email providers such as Microsoft and Google already support this. Google was one of the first to adopt this protocol. The adoption of the MTA-STS by Google and other major companies indicates their interest in creating secure protocols for encrypting email in transit.
Therefore, the best way to ensure the security of our email today is to use the MTA-STS protocol in conjunction with the TLS-RPT to inform us that a failure has occurred.