My next class:

Is it Safe to Require TLS 1.2 for E-Mail

Published: 2019-08-26. Last Updated: 2019-08-27 03:11:37 UTC
by Johannes Ullrich (Version: 1)
3 comment(s)

This started as a quick twitter conversation with Michael Vance (@Mav_Sec):

But a bit background first:

Over the last few years, weaknesses in TLS/SSL have been a major security "headache". But the focus has been HTTPS, and not so much other services, which of course take advantage of TLS as well, and are subject to the same problems. Email is in particular tricky. With HTTPS, the end-user will typically know if they are connecting to an HTTPS site or not, and browsers can warn users about blatant misconfiguration. For email, the user will typically connect to a specific mail server (or use a webmail client). This connection typically happens via HTTPS, SMTPS or IMAPS. But the more difficult problem is how that email is than passed on to other mail servers. By default, this happens in the clear over SMTP on port 25.

To protect these connections between mail servers, SMTP was extended with the "STARTTLS" option [2]. The STARTTLS option allows mail servers to advertise that they are supporting TLS, and the connection will then be upgraded to TLS "on the fly". 

Here is a typical exchange between two mail servers supporting STARTTLS:

220 mail.dshield.org ESMTP
EHLO test
250-mail.dshield.org
250-PIPELINING
250-SIZE 30000000
250-ETRN

250-STARTTLS
250-AUTH LOGIN CRAM-MD5
250-AUTH=LOGIN CRAM-MD5
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN

STARTTLS
220 2.0.0 Ready to start TLS

Note how the server advertises that it supports STARTTLS ("250-STARTTLS"). The client will respond with "STARTTLS" and then switch to TLS as soon as it receives the "220 2.0.0 Ready to start TLS" response. One of the major weaknesses of STARTTLS is that this exchange is not protected, so downgrade attacks are possible. But Michael's question was more about the TLS parameters that are negotiated after this handshake is completed.

Today's email landscape is very centralized. Most email uses a small handful of large cloud-based mail providers (GMail, Office365, Hotmail, Yahoo...). To figure out the TLS configuration of popular email providers, I used a list of "100 Most Popular Email Domains" [1], looked up the MX records for these domains and then connected to them via a Python script testing for STARTTLS support. In addition, I also looked at some connections to my personal mail server. I captured the traffic and used tshark to extract some of the TLS parameters.

First of all: 90% of mail servers did support STARTTLS. Only 9 major providers do not support STARTTLS:

  • sohu.com (Large Chinese Webmail Provider)
  • sinanode.com (also based in China)
  • yahoo.co.jp (Yahoo's Japanese subsidiary)
  • Frontiernet.net (regional US ISP)
  • bol.com.br (Brasilian free email provider)
  • tiscali.it (Italian ISP)
  • tin.it (Italian ISP)
  • untd.com (United Online, Juno/Netzero, low-cost US ISPs)
  • alice.it (part of tin.it. See above)

However, among the ISPs/email providers that support STARTTLS, there was only one that didn't support TLS 1.2: Orange.fr (large French ISP) did only support TLS 1.0.

So what does this mean: Enforcing STARTTLS does not seem practical unless you use protocols like MTA-STS [3]. For mail servers, it is probably too early to recommend dropping support for TLS 1.0. TLS 1.0 is still a lot better than sending email in the clear. Dropping support for TLS 1.0 can lead to some difficult to track down email issues, even if it may affect only a handful of ISPs. I would recommend that you log the ciphers used in your environment. It is pretty easy to log TLS versions using a network tool like Zeep [4]. Or you may be able to log the ciphers used using your mail server logs.

This was a very quick experiment, and probably not the last word in this matter. I am interested to hear from anybody who tightened their TLS configuration. 

[1] https://email-verify.my-addr.com/list-of-most-popular-email-domains.php
[2] https://tools.ietf.org/html/rfc3207
[3] https://tools.ietf.org/html/rfc8471
[4]https://www.zeek.org/current/exercises/ssl/index.html

 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

Keywords:
3 comment(s)
My next class:

Comments

I believe footnote [3] https://tools.ietf.org/html/rfc8471 ... should actually be [3] https://tools.ietf.org/html/rfc8461
Just my 2 cents;
Unless you have an incredibly well controlled environment for mail, it's probably not (yet) viable to require TLSv1.2.

However, to protect user credentials you can require TLS before auth. But it again depends on how much control you have over the user environment if it's viable to mandate TLSv1.2 for that.

Another thing to keep in mind for anyone who is thinking about mandating TLSv1.2 for STARTTLS connections; If you do also still allow unencrypted connections for legacy clients, remember that if you disable TLSv1 and v1.1 that clients not yet supporting TLSv1.2 may now suddenly fall back to entirely unencrypted traffic as they can no longer negotiate a TLS connection. So you'd have people who might have been using acceptable encryption before now being unable to have encrypted traffic at all anymore.
Since january 1st, TLS has been a legal minimum requirement here in Denmark on anything with personal data. So we started to enforce mandatory TLS on all outgoing mail, and made exceptions on a few senders where delivery was considered more important (part of the GDPR risk analysis). 99% of our outgoing mail is TLS encrypted. Exceptions are mostly eastern Europe, as southern European ISPs (I consider France somewhat sotuhern european inefficient). We have a list of maybe 100 domains where we disabled forced TLS. So yes, we are at a point where it is absolutely possible. I work for a 55.000+ employee retailer.

Out of 300.000+ outgoing mails for the last week, 99% used TLS. Microsoft does not make it easy to see which domains are giving you trouble.

Now the danish data authorities has relaxed the requirements to optional TLS, we will fallback to optional TLS. But I am getting less than 1 complaint per month. Maybe one every 2 months.

Update: just implemented the fallback to optional TLS except a few special partners with forced TLS.

Diary Archives