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|