Encrypting email in transit makes a heap of sense

Mainstream media such as the Washington Post (which, as someone living in Ireland, is high on my daily must-read list) got quite excited about Google’s recent announcement that they will name and shame email domains who don’t encrypt inbound and outbound SMTP connections via Transport Layer Security (TLS). The idea is to protect email in transit and so stop snoopers who might want to intercept messages as they travel across the many Internet hops that usually take messages from one domain to another.

Google maintains a site to allow you to explore the data that they gather and discover how common domains do in terms of the percentage of encrypted in-transit traffic. The data is interesting and it forces you to think.

I think this is a good initiative from Google because it is clearly in everyone’s interest to protect privacy by preventing the clear-text transmission of email. Sure, some of the more email-literate users have already taken the necessary steps to protect their privacy by encrypting message contents with PGP or S/MIME, but the simple fact is that most email users don’t realize that anything is amiss. After all, as the cloud providers keep on telling us, email is a utility.

There are many reasons why companies run email servers that don’t use TLS. Sometimes it’s due to cost as certificates are required to enable TLS. Sometimes it’s due to blessed serendipity as old servers remain untouched (and unloved) but are used by applications or humans to dispatch email. And sometimes it’s a fear that enforcing TLS might cause disruption to business-to-business communications because other domains haven’t secured themselves.

In any case, the PRISM revelations and subsequent discussions mean that it is a good time to ask if your company’s email communications are secure and if not, why not. Exchange has long supported "domain security"  (this article covers how for both Exchange 2010 and 2013) to secure SMTP traffic between specific domains and this feature is often used to protect information between partner organizations. On a more general note, Microsoft has improved coverage in Exchange 2013 by making more extensive use of TLS to secure message transport: self-signed certificates are in place for use by TLS for inter-server connections; opportunistic TLS is used to protect inbound traffic to Exchange and Exchange will automatically attempt to use TLS for outbound SMTP connections. Much the same protection is available in Exchange 2010 and TLS can also be deployed to protect Exchange 2007 SMTP communications. And of course, Exchange Online in Office 365 takes full advantage of TLS to protect communications whenever it can.

Good as this is, it’s only one step along the path to protect privacy and security in email and the full end-to-end path followed from client to eventual delivery at the destination must be examined to determine whether message contents are truly protected. It’s not just Exchange, Office 365, or Gmail that has to be examined – every single appliance that can dispatch or receive SMTP communications on behalf of your company should be reviewed as should the clients used to create and read messages.

Your company might come out of such a review smelling of roses with all email communications fully protected and secure. On the other hand, it’s possible that some hard work and disruption might be required to secure email to an acceptable level. Of course, “acceptable” differs from company to company and varies across industries and regulatory regimes. But it makes sense to ask some pertinent questions like “can we really send confidential information in email and be sure that that content cannot be intercepted or read by unintended eyes?”

New technology like Data Loss Prevention comes along to help users do a better job of handling sensitive information like credit card data in email. But the fact remains that a lot more confidential information circulates in email than most business executives could possibly imagine.

Sitting down with a network protocol analyzer like WireShark to examine outbound SMTP communications might be an instructive way to determine just how much confidential information passes through email. It might also lead to some shock that in turn forces the right action to be taken. And it might even keep your company out of Google’s dreaded name and shame list of unencrypted email domains. Wouldn’t that be a good thing?

Follow Tony @12Knocksinna