STARTTLS Adoption Update

Updated October 1, 10:40am Pacific

In May 2013, Facebook published a detailed survey of Transport Layer Security encryption usage by the world’s email servers. That survey indicated that about 37% of mail servers (as measured by IP address) did not at the time advertise the availability of Transport Layer Security (TLS) encryption for protecting the privacy of email sessions and data.

Fast forward to September, 2015 and the picture is improved, but not as much as we would have hoped. Analyzing email traffic sent to a diverse set of over 17,000 25,000 Internet email servers during a two hour twelve hour period on September 30, we found that TLS encryption is now advertised by 72% of mail servers (28% do not advertise it). This implies that the TLS encryption hold-outs have been reduced from 37% to 27% – an improvement of about a third in two years. That’s not a bad improvement, but it’s less than we had hoped for.

What can we learn from this data?

First, it’s great that the vast majority of mail servers are now able to encrypt email sessions. Encryption of email sessions using TLS goes a long way toward preventing interception and modification of email traffic as it crosses the Internet backbone. However, it’s worrying that more email receivers aren’t enabling encryption, despite Edward Snowden’s revelations about Internet snooping, and enormous press coverage of nation-state corporation espionage.

Why isn’t TLS more widely adopted?

Probably because of challenges understanding and working with certificates. Reviewing the documentation for major email server packages (see links below), we found that while it’s straightforward to enable TLS functionality in the mail server, generating and managing digital certificates required to implement TLS is a complex and confusing process. For instance, here is the Exchange “cmdlet” that you must issue to generate a certificate for Microsoft Exchange Server 2010 for the hypothetical domain “contoso.com”, according to Microsoft’s own documentation:

$Data1 = New-ExchangeCertificate -GenerateRequest -FriendlyName "Internet certificate for mail1" -SubjectName "DC=com,DC=Contoso,CN=mail1.contoso.com" -DomainName mail.contoso.com
Set-Content -Path "C:Certificatesmail1-request.req" -Value $Data1

To understand this command, an inexperienced system administrator would need to know:

1. What a certificate is;
2. What the weird “DC” and “CN” terms mean in the SubjectName parameter;
3. What a certificate request is;

… never mind understanding how public key encryption works, and why it’s important to get the parameters exactly right. The following image from IBM illustrates the confusing world of X.509 certificates:

We anticipate that, so long as configuring TLS is difficult (and this hinges critically on the difficulties of generating certificates), adoption of TLS by the remaining hold-outs in the email world will be painfully slow. Email users who wish to make a difference should consider enforcing mandatory TLS: this means only talking to mail servers that support Transport Layer Security. Enforcing mandatory TLS is a bold step, because it generates a high rate of errors; however, if the privacy of your email communications are paramount, mandatory TLS may be a step worth taking.

• Postfix – enabling server side TLS
• Exim – TLS settings
• Microsoft Exchange (2000, 2003) TLS
• Microsoft Exchange (2007) TLS
• Microsoft Exchange (2010) TLS