There have been some articles and even tutorials describing TLS as a simple, interoperable technique for achieving private email communication that is safe from prying eyes of unauthorized users.

The notion is just pure nonsense and lulls non-technical users into a false sense of security. This blog explains how TLS fails to provide adequate protection to emails with sensitive information.

When a user (Sender) sends an email to another user (Recipient) over the Net, the Sender’s email application hands off the message to the email server (called MTA) specified in the mail account configuration. This hand-off could be and should be done with TLS so that other users in the Sender’s organization cannot snoop the message content. The MTA then delivers the message to either the Recipient’s email server or some other email server for subsequent routing to the Recipient. Thus the message may pass through multiple email servers before it is delivered to the Recipient’s email server.

Vulnerabilities in TLS for Email Encryption

Vulnerability #1

The route from one email server to another along the way may not be protected with TLS. This will leave the email message and its sensitive content wide open for anyone to see and even save for future use. Anyone with a PC and sufficient knowledge to sniff the network can 'capture' the email message for its worth.

Vulnerability #2

Let’s suppose for the moment that every route segment along the way is protected with TLS. This still leaves the email message and its sensitive content wide open at the intermediate email servers.

Let's give a 'human face' to this vulnerability. At every intermediate email server, the email message can be read by employees in charge of the server infrastructure or hackers who hacked into the infrastructure. The 'private' email message is no more private than a postcard. never mind that the postcard happens to contain social security numbers and other identity information!

Does that imply that TLS is useless?

No. Far from it, TLS is designed for and provides good protection for data sent from point 1 to point 2. But it does not provide protection over multiple hops as generally is the case with email transportation and it does not protect the data once it is at an intermediate server. TLS provides a protected ‘pipe’ through which unprotected email is sent. All the ‘joints’ and ‘pipes’ downstream have complete access to the unprotected data.

To truly protect private emails, one has to encrypt the data itself such that only Sender and Recipient can have access to the unprotected data. Every entity in-between must be unable to remove the protection layer and access the unprotected data.

What is the solution? Is it standard and interoperable?

SMIME is an industry standard for encrypting emails. This standard is recognized by almost all email applications and servers. The devil is in the details. Email encryption requires keys specific to the Sender and Recipient for every Sender and Recipient. And the right keys need to be distributed to the right parties. Vendors (including us) have created systems that do all of these transparently. However, these approaches are not standardized and therefore not interoperable. It is likely that a standard might emerge.

Summary

TLS is not the solution for implementing privacy-protected email. Standards-based email encryption systems are recommended for true privacy and compliance, with a caveat that interoperability between various systems is not quite there yet!

Not perfect, but that's the way to go for protection and compliance.

Tags: TLS | email encryption | privacy-protected email | Secure email