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

[Brian Conley]

This last bit is a straw man, in my opinion:

"The days where it was possible for two people to have a truly private
conversation over email, if they ever existed, are long over."

If I don't want the existence of a conversation to be known about, I don't
make a phone call, send a letter, start an IM, or send an email.

However, the idea that users don't consider sealed envelopes to contain
private communication is just absurd. Our metadata is not the only thing to
protect, however in this day and age, automated collation and storage of
metadata is certainly worrisome.

I still believe there should be legal protections stating that
communication between two individuals should be considered private and only
those individuals should be in a position to share that information.
Service providers now have technical access to the entire contents of our
communications, whereas postal workers only had access to the
metadata(send/return address). That doesn't mean we shouldn't have laws
protecting the content of that communications and clarifying that service
provider us only a transport mechanism and not a recipient of the
communication.
 On Aug 25, 2013 9:41 AM, "LilBambi" <lilbambi at gmail.com> wrote:

> 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--
> --
> Liberationtech is a public list whose archives are searchable on Google.
> Violations of list guidelines will get you moderated:
> https://mailman.stanford.edu/mailman/listinfo/liberationtech.
> Unsubscribe, change to digest, or change password by emailing moderator at
> companys at stanford.edu.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20130825/bb5e218b/attachment.html>