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.
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
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
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
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: firstname.lastname@example.org)
by my.domain.tld (Postfix) with ESMTPSA id C4C328BF
for <email@example.com>; 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.