[liberationtech] Why can’t email be secure? - Silent Circle Blog

[LilBambi]

I thought this was very important.

--snip--

Why can’t email be secure? - Silent Circle Blog

Posted on August 16, 2013 by louiskowolowski2013

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 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 I am. 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.

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 at my.domain.tld)
by my.domain.tld (Postfix) with ESMTPSA id C4C328BF
for <user2 at 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 above sample is a simple case, which 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.

--snip--