TLS downgrade attacks

Question

I'm currently looking at e-mail security and wondered whether server to server e-mail communication that enforces TLS, will prevent the risk of TLS downgrade attacks?

Answer 1

TLS Downgrade attacks consist of a MITM threat actor forcing the weaker TLS/SSL protocols because the server permits the weaker protocols. Server-to-Server is still possible but client-to-server is the most likely.

A good candidate for an attackers success:

In this scenario, the attacker in the simplest form, drops the packets of the victim requesting the higher protocols, thus the downgrade attack, then the client retries lower protocols. This downgrade gives the attacker a high probability of being able to acquire session cookies, modify traffic, steal credentials, intercept emails, etc.

Victim   - Supports SSL 2.0, 3.0: TLS v1.0, v1.1, v1.2, v1.3
         - Supports High, Medium, Weak, CBC, and Null Ciphers
Attacker - Has Successful MITM
Server   - Supports SSL 2.0, 3.0: TLS v1.0, v1.1, v1.2, v1.3
         - Supports High, Medium, Null Ciphers

A good candidate for an admin's success:

In this scenario, the attacker can attempt to try and modify the negotiations but the server is hard set, use high protocols and ciphers, or nothing. The attacker really has no chance to decrypt the communications. Or at least not yet... Computers in 5-10 years will be different and these protocols will become outdated. IETF already has a draft for decommission of TLS v1.1.

Victim   - Supports SSL 2.0, 3.0: TLS v1.0, v1.1, v1.2, v1.3
         - Supports High, Medium, Weak, CBC, and Null Ciphers
Attacker - Has Successful MITM
Server   - Supports TLS v1.1, v1.2, v1.3 or just TLS v1.2 & v1.3
         - Supports High Ciphers only

Answer 2

There are actually two problems with SMTP over SSL/TLS via STARTTLS:

1. The STARTTLS downgrade problem. Let's suppose that the receiving MTA supports STARTTLS, and advertises that it does so in the EHLO banner. An MITM can simply strip the STARTTLS advertisement from the banner. Then the sending MTA thinks the receiving MTA doesn't support TLS, and the session proceeds in plain text.

You might say, I'll solve this problem by only supporting SSL/TLS. If the other side doesn't upgrade to SSL/TLS via STARTTLS, I'll abort the session. Of course, this means that you won't be able to exchange mail with MTAs that don't support SSL/TLS, but maybe you're OK with that. Fine, but how do you handle certificates? That brings us to:

2. The certificate problem. Let's assume my email address is [email protected], and I use myemailprovider.com to host email for my domain. So, when you do an MX lookup for mycompany.com, it resolves to mx.myemailprovider.com. Now, you send me an email, so your outgoing SMTP server connects to my incoming MX server, mx.mysmtpprovider.com. The two servers agree to upgrade the connection to SSL/TLS by way of STARTTLS. Then, what certificate should your outgoing SMTP expect to see? A certificate for mycompany.com? No, that's not the way it works (in fact, it's impossible, because mx.myemailprovider.com doesn't even know the recipient of the message yet (because your outgoing SMTP server hasn't send RCPT TO yet), and mx.myemailprovider.com hosts incoming mail for many other domains in addition to mine). The certificate that mx.myemailprovider.com presents is their certificate, for mx.myemailprovider.com.

Why is this a problem? Well, consider a DNS poisoning attack on the sending MTA, that serves the sending MTA a false MX record for mycompany.com. Instead of returning the correct MX record, mx.myemailprovider.com, the attacker returns mx.attackersserver.com. Then, your sending MTA connects to mx.attackersserver.com. mx.attackersserver.com advertises that it supports STARTTLS, so the sending MTA and mx.attackersserver.com upgrade the connection to SSL/TLS, and mx.attackersserver.com presents its own certificate (which any CA hsppily to signs, because the attackers can easily verify that they own mx.attackersserver.com, because after all, they do in fact own mx.attackersserver.com). The sending MTA sees a valid certificate for mx.attackersserver.com, so it happily proceeds with the SMTP session, and sends the email that you intended to send to me, to the attacker. Wonderful, right?

These problems stem from the fact that we are still using an insecure protocol (SMTP) that was developed in the 1980's, in 2019. Supporting STARTTLS is better than nothing, but it's a bolt-on, and like many bolt-on's it can be defeated. DNSSEC can be used to mitigate these problems to some degree, but DNSSEC also has it's own shortcomings.