A blog article I did for Silent Circle back in August, about why email (in its current form) can’t be secure .
Just use a plugin
Coming on the heels of our announcement that we had shut down our Silent Mail service, we received a comment about securing email communications.
In a recent press release, your company stated it was impossible to
secure email communication ‘as we know it’. To me, it would seem to
be a very easily solvable problem. Simply write a plug in for
popular email applications that automatically applies asymmetric key
cryptography to any emails being exchanged between people who both
possess the plugin. Granted this would not work until the keys were
exchanged but the plugin would make that trivial.
If the goal is simply to encrypt the body of the message there are services and products that accomplish this. You could use traditional PGP/SMIME to encrypt the body of the message. If you were to do this, you would still have to manage the keys yourself. You could go a step further and have a server that manages keys/users for you, or a collection of federated servers. Such a beast might look very much like the PGP Universal server. For an individual, a server, or collection of them probably isn’t practical. For a company, it could make sense.
One would encrypt the body of the message if it contains information that is more important than the meta data of who is communicating, and how often. For example, a company could want to protect intellectual property this way. An individual could want to send tax documents to their accountant. In both cases, who is communicating with whom is less important than what is said in the body of the message.
Leakage?
If your goal is to not have metadata leakage in your otherwise secure communications, you may wish to avoid email altogether. Email leaks the information about who is communicating, and how often. This information may be just as damaging as the content of the email. For example, a freedom fighter working in an oppressive country, trying to get the word out.
In the above scenario, you suggest a plugin that would exchange information, such as keys (required to perform public key cryptography). Lets assume for a moment that nobody uses webmail, and everybody uses an email client that can accept this plugin. Email works by finding the domain for a given user and sending mail to the server claiming responsibility for the address. The user is not required to be online.
If you put a plugin in your email client that needs to exchange keys with another party, you would require that the other party be online at the time you wish to send your message. That’s awkward when you wish to email somebody half-way around the world from where you are. This plugin would have to communicate over a defined port. Communication over this port could imply you are trying to send an encrypted message to somebody. Its unlikely you could use a well known port (such as tcp/443), because most ISPs block that kind of traffic inbound to residential users.
What about the headers?
Additionally, email provides no means to secure the headers (routing information, and the envelope). The routing information, which is visible by looking at the headers of any email message, by design, is all unencrypted. Any server in the path between sender and recipient, can view any portion of the headers, as they are stored as plain text in the beginning of the message.
The following is a sample set of received headers that has been sanitized.
Received: from host.local (some.corp.domain.tld [192.168.0.58])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
(Authenticated sender: user@my.domain.tld)
by my.domain.tld (Postfix) with ESMTPSA id C4C328BF
for <user2@my.domain.tld>; Mon, 29 Jul 2013 14:15:22 -0700 (PDT)
Received: by host.local (Postfix, from userid 501)
Subject: Pricing info for blasting caps
The sample above is a simple case of one server connecting to another server and sending a message to a user on that server. You can see the name of the host that connected, the IP of the machine that connected, the recipient of the message, whether or not encryption was used, and if so, what kind of cipher and key size). None of this can be encrypted if you want to be compatible with current email protocols. The time and timezone can be equally valuable. You can also pull the subject, sender metadata (To, From, MUA, etc) which is also stored and transmitted in the clear. So a PGP-encrypted message with the subject line “Pricing info for blasting caps” may be sort of ridiculous. You can also learn a lot from frequency and who is associating with whom but that’s a separate post about traffic analysis probably. MUA tells what kind of platform someone is using, sometimes even versions. You could probably have a lot of fun talking about that.
The above sample uses TLS to secure the communication between the client and host mailserver. In order to prevent a 3rd party from being able to view the message as it moves from server to server, all links would need to support, and use, TLS. Steve Gibson (GRC) recently did a survey of 4 major mail providers in the US. Hotmail, AOL, Yahoo, and GMail. The only one to even offer TLS was GMail. While they offer a secure communication between the client and their own mail server, email that gets sent to another provider is all sent in the clear.
As you can see, email security has become more complex than it used to be. In the past, securing the body of the message was sufficient. The tools and techniques used for snooping were not on a large enough scale to allow the metadata to be useful. With the tapping of backbone internet providers, interested parties can now see all traffic on the internet. The days where it was possible for two people to have a truly private conversation over email, if they ever existed, are long over.
Comments