Let’s start our quick history lesson by setting the scene; Madonna was topping the charts and Kevin Mitnick had just been arrested after nearly three years on the run from the authorities. It’s February 1995 and researchers at Netscape had just released SSL version 2.0, much of the work was credited to Taher Elgamal, often referred to as the father of SSL. SSL version 1.0 was being worked on before that, but was never published.

Things didn’t start out great; SSL 2.0 was quickly discovered to contain a few bad flaws making it vulnerable to man-in-the-middle attacks, amongst other things. It was also impractical to implement especially for web hosting providers since it only supported a fixed domain certificate. SSL 3.0 addressed the issues found in SSL 2.0, and has been in use since 1996. It wasn’t until the discovery of the POODLE attack in 2014 that things started looking grim for SSL 3.0, which was subsequently deprecated in 2015.

TLS 1.0 is basically SSL 3.1, but the protocol was renamed as it was standardised by the IETF. It was first defined in 1999, and the result of a deal struck between Netscape, Microsoft and the IETF. Remember, this was in a time when the browser war between Netscape and Microsoft, and Microsoft had even introduced their own protocol derived from SSL 2.0 only supported in Internet Explorer and their web server IIS. The IETF wanted a standard, and that’s where TLS comes from.

From there on, it’s basically the same story all over again, but with more openness and collaboration. Each TLS version from 1.1 to 1.3 tightened up security, added features and removed old functions. TLS 1.0 and 1.1 were both deprecated in 2020, leaving us with TLS 1.2 and 1.3 as the only versions currently not deprecated.

Impact on email security

Alright, but how does this impact in-transit security for email? Let’s start by talking about SMTP. For server to server communication, opportunistic TLS is what happens in most of the cases. If one (or both) of the servers doesn’t support SSL/TLS the transaction continues unencrypted.

220 mx.halon.io ESMTP // Server introduces itself
EHLO halon.email      // Client sends extended hello
250-mx.halon.io       // Server replies with its capabilities
(cut)
250-STARTTLS          // Informing the client that SSL/TLS is available
(cut)
STARTTLS              // Client asks for the session to be encrypted
220 2.0.0 Ready to start TLS
(handshake and encrypted session)

This by design is vulnerable to man-in-the-middle via downgrade attacks. A malicious party on the line with the ability to modify traffic could very easily force the transaction to continue unencrypted by just dropping the 250-STARTTLS reply. And since there’s no straight forward way of verifying certificates as with HTTPS, it becomes a bit tricky to solve. Two solutions to this problem are DANE and MTA-STS. DANE relies on DNSSEC to establish trust, MTA-STS relies on CA issued certificates.

How to act and what to think about

What TLS protocol versions should you support, since you could argue that even the worst of encryption is better than nothing? Well, Google/Gmail supports TLS 1.2, but also the deprecated 1.0 and 1.1, for inbound and outbound SMTP. Microsoft/Outlook only support TLS 1.2 for both directions. Neither support the older SSL versions. Both will obviously send and receive emails in plain text, if the other party doesn’t support TLS (as is the norm today). To sum things up; make sure that you support TLS 1.2 or higher. Since Microsoft has disabled support for the deprecated TLS 1.0 and 1.1 protocols for server-to-server SMTP, you could probably too. By doing so however, there is a risk that traffic from and to older systems will be sent unencrypted.

More importantly, you should use DANE and/or MTA-STS for your inbound traffic, and validate both DANE and MTA-STS for your outbound traffic. Since these are two competing standards right now, supporting both is probably your best course of action. For sending outbound traffic, Microsoft does MTA-STS checks, whereas Google doesn’t according to our testing. Neither checks DANE, but Microsoft has announced that this will be implemented in December 2021, with inbound DANE coming in December 2022.

When it comes to end-user client communication there’s more protocols to consider in addition to SMTP; mainly IMAP, POP3 and HTTP (for webmail). This is slightly more straightforward, since the user have interactive control over what is happening. Because client connections are generally authenticated with a username and password, it’s a good idea to require TLS if at all possible. This can be done either via implicit TLS; that means running SMTP over port 465, IMAP over port 993 and POP3 (if you still use that) over port 995. The alternative is to use STARTTLS on the default ports, but then it’s important to configure the server software to require TLS to be started, if that’s your policy. Instruct your users to always take extra care to inspect the certificates in use; certificate warnings could be a strong indicator of someone interfering with your traffic.