We need to talk about email

Filed Under: Featured, Google Chrome, Google, Cryptography, Yahoo

Sometimes big security problems go unfixed for so long that they sort of disappear.

They can disappear without being fixed or mitigated. They can disappear without anyone forgetting they exist or forgetting that they're serious. They can disappear just because they become normal.

Today the people of the world will exchange about 250 billion messages using a system that has been shockingly insecure for decades: email.

Many of those billions of messages will contain personal, private or even confidential information because most of the people sending them just don't know how easy it is to read somebody else's email.

As security problems go, email insecurity may not be fashionable, it isn't bleeding edge, and it doesn't have a logo or a PR friendly name like Heartbleed or Cryptolocker.

But it's no less important.

To understand why email is so insecure let's take a look at how an email gets from A to B.

How email travels

Emails travel from their source to their destination through a network of computers joined together by cables or Wi-Fi signals.

The computers and other hardware on the network negotiate the best delivery route for your traffic, including your email, as it passes through.

Your email might go directly from your own email server to the recipient's email server – for example in business-to-business messages – where it is treated very specifically as an email.

But the contents of the message (chopped into chunks the size of network packets) pass quietly through all the computers in the network chain.

Most of these computers aren't mail servers, so they essentially ignore the message, or don't bother to take special notice. At least, the ones that don't have a packet sniffer on them ignore it. Probably.

Of course, even if a computer only gets to see your message flying past in fragments, it's still easy to spot that it's an email, because the fragments contain give-way signs.

These include Simple Mail Transfer Protocol (SMTP) commands like HELO sending.server.example and MAIL FROM: <sender>, as well as telltale email headers including content hints like Subject: Very Important! or information on the delivery path followed so far in the form of Received: from mail.gateway.example.

Additionally, as your email makes its way its way from email server to email server, it is logged and its contents stored in their entirety, at least temporarily, on each and every server it passes through.

In many cases, anyone who is a sysadmin on any of those servers will be able to examine, copy, delete, and perhaps even modify, your messages and the logs of their journey.

Of course, on the internet, the route an email takes from A to B can include hardware, cables and airspace operated, owned or pwned by any number of countries, organisations or individuals. Implicitly, email trusts them all.

At any point or points on its journey the email may be scanned to determine if its content resembles spam or contains malware.

Its contents may also quite deliberately be read and interpreted (even without the sender's consent) to determine what kinds of advertising the recipient is most likely to respond to.

Put another way: an email is like a postcard that's delivered by passing it from hand to hand through a crowd of strangers.

Given its very public and overly trusting means of delivery it should be pretty clear that there's really only one sensible way to keep an email secret: to put it in a container with a padlock that only the recipient can unlock (or, in computing terms, to encrypt it in a way that only the recipient can decrypt).

So, of course, that isn't how we do it.

The best way to secure email

Like a lot of the early network protocols, SMTP was conceived without any thought of security at all.

Early network protocols like Telnet, File Transfer Protocol (FTP), the Domain Name System (DNS) and SMTP were ground-breaking technologies that transformed computing.

They were born into trustworthy environments and raised by trustworthy folk who simply couldn't imagine what obstacles and villainy their work would face in the decades that followed.

First we built the internet and then, only after we understood the nature of what we'd made, did we begin to secure it retrospectively.

That process is still going on and for the first generation of internet technology security has either been too much altogether or a difficult, better-late-than-never bolt-on.

Adding a layer of security to a system that's as deeply entrenched as email is no small matter.

However the means to secure emails properly has been available, thanks to Phil Zimmermann and his creation PGP, completely free of charge for at least 23 years.

PGP and the OpenPGP standard that followed delivered end-to-end encryption: the ability for a user to encrypt an email in way that only the recipient can untangle.

Unfortunately almost nobody uses it.

The chances are that you already use an email client that supports PGP encryption but still send unencrypted mail.

There are many reasons that end-to-end encryption isn't used: people don't know it exists; they don't know why they need it; it's optional; it can be difficult to understand; it can be difficult to set up; and it doesn't deliver an immediate and satisfying reward.

Worse still, the recipient has to be willing to join in too, or they won't be able to read your messages.

Whatever the reasons, the fact is that leaving it for users to bolt proper security onto an email system they're happy with simply hasn't delivered the goods.

Which is what led us to the second best solution.

The second best way to secure email

The second best option for email security, and the only option that is actually used on any kind of meaningful scale, is to encrypt the communications between the servers in the delivery chain using TLS (Transport Layer Security).

The emails can't be intercepted when they're travelling between servers, but that's it.

They aren't encrypted before they leave your computer, or while they're being processed by the email servers that pass them along, or after they reach their final server.

An email delivered over TLS still implicitly trusts every server it passes through, as well as the network at each end, used by you to create the email and have it queued for delivery and by the recipient to retrieve it and read it.

Nevertheless, TLS keeps the content of messages secure in transit, and has two main factors in its favour over end-to-end encryption: it can be rolled out by changing far fewer computers (only mail servers need reconfiguring), and setting it up is more often in the hands of experts than end users.

Sadly, any two servers in the delivery path of your emails will only put up an encrypted "tunnel" for your message if both sides know how, and agree to bother.

That happens far less often than you'd hope.

According to its transparency report, Gmail (which only rolled out 100% encryption between its own servers in March 2014) skips encryption on 25% of outgoing connections and 43% of incoming connections.

In other words, Gmail stands ready to create TLS tunnels to secure your email packets in transit, but between one half and one quarter of their nearest neighbours in the delivery chain can't.

Or don't bother.

That means if you want to do the right thing yourself, and use TLS to guarantee that email is encrypted into and out of your organisation, you have to reject all email from non-TLS senders, and outright refuse to deliver it to non-TLS receivers.

If Gmail's measurements are anything to go by, you can then expect a quarter of your sales proposals not to go out at all, and nearly half of your incoming orders to be lost.

Good luck with that.

Is anything going to change?


Since Edward Snowden revealed that the NSA has been siphoning off vast troves of internet data (including massive amounts of email), encryption and encryption technologies have been given a new lease of life.

The major online service companies have all started issuing transparency reports, encrypting the connections between their data centres and encrypting the connections between web browsers and their webmail products.

Most significantly Google, which seems to have caught the encryption bug most visibly of all, recently announced End-to-End, a Chrome browser plugin that aims to make it easier to use OpenPGP.

You remember OpenPGP – that's the way we should be encrypting email.

It isn't ready yet, but if you're technically savvy enough to compile your own plugin from source you can start testing it today.

The project is significant for two reasons: firstly because it aims to ameliorate the most serious problem with end-to-end email encryption, and secondly because it's open source.

Being open source means that other people can review it, change it, include it in their own products or create their own variations of it.

It might start life as a browser plugin for Chrome but if it works and people like it then it will spread to other browsers and other platforms.

The first such contagion has already occurred with Yahoo's recent announcement that it plans to bootstrap its own PGP plugin using Google's.

In the meantime, the roll out of TLS will continue and of course you don't have to wait for Google or Yahoo to deliver their plugins to benefit from OpenPGP – they're just making something that already exists easier to use.

Yahoo's OpenPGP product will be ready in 2015, some 44 years after Ray Tomlinson sent the first email over a network.

The chances are that when it reaches its half-century email still won't be completely secure, but that still won't be a reason not to talk about it.

Images of post courtesy of Shutterstock.

, , , , , ,

You might like

8 Responses to We need to talk about email

  1. Joe · 407 days ago

    Rather than pinning our hopes on silly (and INSECURE) browser plugins that use PGP (which cryptographer Matthew Green says should be retired), we need a replacement for SMTP. I'm surprised you didn't mention the Darkmail Alliance, which is developing precisely that -- a protocol that won't disclose even the metadata.

    • The Darkmail Alliance are currently nothing more than an announcement.

      I'm not denigrating them - they have some Kickstarter funding and some respectable founders who have done far more for email security than I ever have but right now there's nothing to see and nothing to say.

  2. Victor L-S · 407 days ago

    Mark, do I have this right...

    There are three segments involved each of which might or might not be encrypted.

    1. Sender to mail server
    2. Mail server to mail server
    3. Mail server to recipient

    While an https session between sender to mail server is secure there is no guarantee of similar security between mail server to mail server or mail server to recipient. Hence an https session is not the same as a TLS session.

    Only by requiring an end-to-end secure session or encrypting the email itself can security be insured.

    ..and by the way Sophos https is running properly now on these pages.

    • Paul Ducklin · 407 days ago

      Answering for Mark, just because I'm online right now :-)

      You have it right, although step 2 may actually involve more than one mail server (for example, your server -> ISP's server -> recipient's spam filtering gateway -> recipient's Exchange server). The parts shown with arrows ("->") *between* the servers may or my not encrypted via TLS. But while the mail is being received/scanned/stored/queued *on* each of the servers in the chain, it will not only be decrypted but almost certainly written to disk, possibly more than once.

      If you're using webmail, then you can tack on the front: you -> your browser -> webmail HTTP server -> mail SMTP server. Of *those* arrows, HTTPS only really applies to the second arrow, from your browser to the webmail server.

      If you have an already-encrypted email or attachment, then any HTTPS or TLS steps will simply encrypt it again, stripping off the outer encryption at the other side of the link. So whenever your attachment is decrypted as far as your ISP/mail provider is concerned, it's still encrypted as far as you're concerned.

  3. Anonymous · 407 days ago

    I suspect the real security of emails is the vast daily volume ....who has the resources to filter so much traffic in the off chance of picking up a gem.

  4. Andrew Ludgate · 406 days ago

    Thanks for this! This is more or less the e-mail talk I've been giving people since the mid-90's. Fortunately, PGP/GPG has become a lot more accessible during that time, with things like PGP/MIME replacing the old "capture the clipboard" method we used in the "old days".

    Also, I was impressed that you guys did this article without plugging Sophos' own email security product that doesn't require the recipient to have special software (other than Acrobat Reader). But I guess I've partially done that now :)

  5. Clemens · 404 days ago

    The volume is no protection. Also real world burglars do not break in every home. They do a selection before hand: Wealthy neigbourhood, nobody home etc. . No single burglar will be able to break into all homes, but there are enough burglars around to share the load. Analogous selection and work-share takes place also in the net-world.

    • Paul Ducklin · 404 days ago


      12 months ago, if you'd announced that crooks would be able to harvest *every* credit card number used in *every* purchase at *every* Target store in the *entire* USA [*], racking up 40,000,000 records in about 40 days...

      ...many people would probably have said, "Phoooey. Too much data. Ain't never gonna happen."

      As it happened, the crooks got those 40,000,000 data points, plus another 70,000,000 database entries about Target's customers and prospects, just for good measure.

      [*] Perhaps not every "every" is strictly correct here. But you get my drift, I'm sure.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Mark Stockley is an independent web consultant who's interested in literally anything that makes websites better. Follow him on Twitter at @MarkStockley