The Stack Archive

Why providers need to finish the job of implementing Transport Layer Security

Tue 17 Nov 2015

Adoption of Transport Layer Security (TLS) by service providers is nearing 100%, yet challenges in rolling out the technology remain a barrier to laggards…

Transport Layer Security (TLS) protects the contents of Internet traffic from being read or altered by attackers with access to the Internet links that connect end users and servers; while TLS has flaws, its near total adoption by large service providers has greatly increased the privacy and security of Internet traffic worldwide. Yet challenges remain.

When Edward Snowden revealed the extent to which government agencies such as the US National Security Agency (NSA) and the UK’s Government Communications Headquarters (GCHQ) had tapped into and monitored the world’s Internet communication links, consumers responded with demands for improved encryption to prevent eavesdropping. Under severe pressure in the media, large providers like Facebook and Google launched major encryption projects with lightning speed, including rolling out TLS encryption of email and web communications en masse within months – an epic engineering achievement.

Yet, smaller service providers have been slow to adopt TLS, despite the public outcry over privacy. As CEO of email service provider MailChannels, I can identify with the resource challenges which often delay security projects in favor of other things. But despite the challenges, it’s crucial that providers of all sizes take this issue seriously and put TLS on the schedule.

Post-Snowden privacy trends

In May 2013 , ​Facebook published a survey that showed about 37 per cent of mail servers (as measured by the IP address) did not advertise the availability of TLS encryption for protecting the privacy of email sessions and data.

In September 2015, we analyzed email traffic sent to a diverse set of more than 25,000 Internet email servers during a 12-hour period. We found that TLS encryption is now advertised by 72 percent of mail servers – an improvement of about one-third in two years. This improvement in TLS adoption reflects a concerted effort by thousands of organizations, which we ought to applaud.

But while it’s great that the majority of mail servers are now able to encrypt sessions using TLS, it’s worrying that laggards remain. Until nearly everyone implements TLS, mail server operators have to maintain an open minded policy – connecting in the clear to about 28% of mail servers – that means some portion of email traffic is not encrypted in transit. That relatively small portion can be snooped and modified in transit with relative ease by government agencies.

Challenges and opportunities bump elbows

Why isn’t TLS more widely adopted? Probably because it’s challenging for system administrators to understand and work with digital certificates.

We reviewed the documentation for major email server packages such as Postfix,​ Exim,​and ​Microsoft Exchange 2010, among others. We found that while it’s straightforward to enable TLS functionality in the mail server, generating and managing digital certificates (which are required to implement TLS) is a complex and confusing process.

TLS implementation requires system administrators to know what a “certificate” is, what a “certificate request” is – plus understand how public key encryption works, and why it’s important to get the parameters exactly right.

So long as configuring TLS is difficult (and this hinges on the difficulties of generating certificates), adoption of TLS by the remaining holdouts in the email world will be painfully slow.

Email users who wish to push for broader adoption of the protocol should consider enforcing mandatory TLS. This means only talking to mail servers that support TLS.

It’s a bold step because mandatory TLS generates a high rate of errors. However, if the privacy of your email communications is paramount, mandatory TLS may be a step worth taking.

The future is DANE

TLS is an effective encryption protocol when used correctly. However, it does have some weaknesses that can be exploited by sophisticated attackers. A sufficiently advanced attacker can intercept TCP streams between email servers and remove the STARTTLS ​command from the SMTP stream. This prevents the client from using TLS encryption with the server – even though the server supports TLS.

To avert this type of attack, a new standard called D​NS-based Authentication of Named Entities (DANE)​ lets domain owners tell email senders that their mail server uses TLS – and optionally, to reject connections where TLS is not advertised as it should be. It also allows them to authenticate TLS client and server entities without a certificate authority.

DANE adoption has been slow because it requires domain owners to first implement Domain Name System Security Extensions (DNSSEC). That in itself involves challenges to overcome and potential pitfalls in the transition to better privacy standards.

Internet applications have traditionally relied on third-party certification authorities to ensure that a server holding a specific private key had domain authority. But in the future, DANE will allow domain operators to vouch for their own names.

Ken Simpson is the co-founder and CEO of MailChannels, the world’s foremost provider of outbound anti-spam and email delivery technology. Ken also runs the botnet and web abuse sub-committees at the Messaging Anti-Abuse Working Group (MAAWG).


feature security
Send us a correction about this article Send us a news tip