Over the last two years, the number of encrypted emails received by Gmail has almost doubled, as I reported earlier on the Google security blog. This very encouraging trend is sadly accompanied with an increase of SMTP TLS downgrade attacks, which prevent encryption of emails in transit as discussed in our research paper on the state of email transport security. This blog post explains how such an attack is performed and why there is no simple patch for it. This blog post and the next one on MX record hijacking are meant to fix the lack of publicly available documentation about current attacks against email transport security. Hopefully this will help raising awareness about those attacks and help the community understand of how these attacks work.
Why is encrypting emails in transit important?
When a user from a mail service, lets say Gmail, writes an email to a friend who uses another service, lets say Yahoo, their email provider needs to send the email to the friends provider. The email is sent through the Internet, which means that there is a risk that an adversary, as illustrated in the figure, will read it or even tamper with it. This is why encrypting emails in transit is so important in protecting our privacy and security: it guarantees that no third party can read or tamper with them.
How are emails encrypted in transit?
SMTP (Simple Mail Transfer Protocol, the protocol used to send emails from one provider to another, is one of the oldest protocols in the world and therefore, it was not designed with security in mind. This is not surprising, as TLS/SSL was not even invented when it was conceived: SMTP was invented in 1982 and SSL/TLS in 1999. As a result, security had to be retrofitted to the existing protocol to make sure it was backward compatible.
As visible in the diagram above, this retrofitting was achieved by adding the verb STARTTLS to the SMTP options command that the server sends to the SMTP client as part as the protocol negotiation. If the client supports encryption (TLS), it will understand the STARTTLS verb and will initiate a TLS exchange before sending the email to ensure it is encrypted. If the client doesnt know TLS, it will simply ignore the STARTTLS and send the email in clear.
How does a STARTTLS downgrade attack work?
Because security had to be retrofitted into the SMTP protocol, the upgrade for encrypted delivery has to rely on a command (STARTTLS) sent in clear text. As visible in the diagram above, a man-in-the-middle attacker can exploit this by performing a downgrade attack on the SMTP connection and tampering with the upgrade command. Usually a downgrade attack replaces STARTTLS with a garbage string such as XXXXXXXX. The client sees the garbage string, and it may decide it is an option it doesnt know and so happily falls back to sending the email in clear text. The attacker usually replaces the command with garbage rather than stripping it out because this preserves the packet size and therefore, makes it easier. The eight letters in the garbage string in the option command allow us to detect that a TLS downgrade attack has been carried out and we can measure its prevalence.
Why cant we just enforce TLS?
Actually we do! But only for client-to-server communications, such as Gmail clients to Gmail servers. We are able to enforce it for those connections because we know that the apps and the server support it. For server-to-server communications, we must fail open to allow legacy servers to send emails. The crux of the problem being that we have no idea if the server on the other side supports TLS. Accordingly the fix to this attack is to add a new discovery mechanism that will allow servers to indicate they support TLS, which will allow them to **fail close ** (aka not sending the email) if the upgrade negotiation doesnt happen. This fix is not as simple as it seems because we also need to know which certificates to trust for a given connection and deal with certificate revocation. This explains why this work takes more time than people would think.
Are all TLS downgrade malicious?
Before closing this post, it is worth mentioning that not all the TLS downgrade attacks we observe are malicious. As a matter of fact, some networking equipment, such as that made by Cisco, uses a TLS downgrade to inspect emails for security purposes. That being said, given the risk of such a hole being abused for nefarious purposes, it seems very important to close it. If you found this post useful, please share it on your favorite social networks. This helps me to know if my posts are useful and motivates me to keep writing.
