Subject: [perpass] Gmail is now HTTPS-only

From: Pranesh Prakash <[email-masked]>
Date: Fri, 21 Mar 2014 13:21:42 +0800

Dear all,
Since 2010 Gmail's web interface has been HTTPS by default, but today 
Google announced that they will be disabling the option to make it HTTP:

http://goo.gl/OqKveO

And they also note:

> In addition, every single email message you send or receive—100% of them—is encrypted while moving internally. This ensures that your messages are safe not only when they move between you and Gmail's servers, but also as they move between Google's data centers—something we made a top priority after last summer’s revelations.

Regards,
Pranesh

-- 
Pranesh Prakash
Policy Director, Centre for Internet and Society
T: +91 80 40926283 | W: http://cis-india.org
-------------------
Access to Knowledge Fellow, Information Society Project, Yale Law School
M: +1 520 314 7147 | W: http://yaleisp.org
PGP ID: 0x1D5C5F07 | Twitter: https://twitter.com/pranesh_prakash

---

From: Robin Wilton <[email-masked]>
Date: Fri, 21 Mar 2014 11:40:32 +0000

To pick the obvious nit...

Even if an email goes from my browser to Google's servers over https, and goes between Google's servers over https, I did not see a commitment to encryption of the email when it is at rest, rather than in motion...

R

Robin Wilton
Technical Outreach Director - Identity and Privacy
Internet Society

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

On 21 Mar 2014, at 05:21, Pranesh Prakash wrote:

> Dear all,
> Since 2010 Gmail's web interface has been HTTPS by default, but today Google announced that they will be disabling the option to make it HTTP:
> 
> http://goo.gl/OqKveO
> 
> And they also note:
> 
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Mar 2014 08:27:28 -0400

> Even if an email goes from my browser to Google's servers over https, and goes between Google's servers over https, I did not see a commitment to encryption of the email when it is at rest, rather…

Best is the enemy of good enough.   To compromise your mail on the server, they have to compromise the server.   To compromise it in flight, they just have to tap the network.

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 21 Mar 2014 06:00:04 -0700

> Even if an email goes from my browser to Google's servers over https, and goes between Google's servers over https, I did not see a commitment to encryption of the email when it is at rest, rather…

To reply with the obvious:  It is IMPOSSIBLE to secure data at rest in the context of a webmail system: server control can always enable accessing of all documents when the user logs in to check their webmail.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Robert Story <[email-masked]>
Date: Fri, 21 Mar 2014 09:10:49 -0400

On Fri, 21 Mar 2014 06:00:04 -0700 Nicholas wrote:
NW> > Even if an email goes from my browser to Google's servers over https,
NW> > and goes between Google's servers over https, I did not see a
NW> > commitment to encryption of the email when it is at rest, rather than
NW> > in motion...
NW> 
NW> To reply with the obvious:  It is IMPOSSIBLE to secure data at rest in
NW> the context of a webmail system: server control can always enable
NW> accessing of all documents when the user logs in to check their webmail.

Unless the client does the decryption locally... If gmail offered this
option, I'm sure browser plugin writers would meet the challenge quickly..

Robert

--
Senior Software Engineer @ Parsons

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 21 Mar 2014 06:12:53 -0700

> option, I'm sure browser plugin writers would meet the challenge quickly..

That is no longer webmail.  It would have serious usability problems.  And to further put the obvious, even that provides no protection for incoming messages.

---

From: JOSEFSSON Erik <[email-masked]>
Date: Fri, 21 Mar 2014 14:29:40 +0000

I would very much like to have Mailpile in the next version of DebianParl:

https://mailpile.is/

https://wiki.debian.org/DebianParl/

Someone just needs to package it and take it to stable.

//Erik

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 21 Mar 2014 10:47:33 -0400

> Someone just needs to package it and take it to stable.

The best way to start this process is to file a "request for packaging"
(RFP) bug in debian.  If you're already running some flavor of debian,
and you have the reportbug package installed, you can just do:

 reportbug wnpp

select "RFP" from the set of choices, and fill in the report.

the actual packaging work will take time (whether you want to undertake
it yourself or not), but knowing that users actively want the package is
a nice incentive for packagers to work on it.

Regards,

	--dkg

---

From: Richard Barnes <[email-masked]>
Date: Fri, 21 Mar 2014 10:53:04 -0400

On Fri, Mar 21, 2014 at 8:27 AM, Ted Lemon <[email-masked]> wrote:

> > Even if an email goes from my browser to Google's servers over https,
> and goes between Google's servers over https, I did not see a commitment to
> encryption of the email when it is at rest, rather than in motion...
>
> Best is the enemy of good enough.   To compromise your mail on the server,
> they have to compromise the server.   To compromise it in flight, they just
> have to tap the network.
>

Mail on the server is precisely what PRISM went after.
<http://en.wikipedia.org/wiki/PRISM_(surveillance_program)>

Which would you rather do, dig up a sub-sea cable, or tap a server admin on
the shoulder?

--Richard

---

From: Robin Wilton <[email-masked]>
Date: Fri, 21 Mar 2014 15:01:47 +0000

> Best is the enemy of good enough.   To compromise your mail on the server, they have to compromise the server.   To compromise it in flight, they just have to tap the network.
Oh, I'm not suggesting that deployment of https should be deferred until there's end-to-end encryption. I'll certainly take https if it's offered. I was just pointing out that this announcement doesn't represent a change in Google's business model of monetizing the contents of Gmail correspondence.

R 

Robin Wilton

email: [email-masked]
Phone: +44 705 005 2931
Twitter: @futureidentity

---

From: Robin Wilton <[email-masked]>
Date: Fri, 21 Mar 2014 15:10:22 +0000

> To reply with the obvious:  It is IMPOSSIBLE to secure data at rest in the context of a webmail system: server control can always enable accessing of all documents when the user logs in to check th…

I'd dispute your use of the word "impossible". It might be tricky to design something easy to use, and it would raise the usual end-to-end encryption problems of key exchange and key management, but there's nothing inherent in webmail as a transfer mechanism that means it can't transfer encrypted content. For instance: last time I used the PGP tools, they offered the ability to encrypt whatever's in the clipboard. There's nothing to stop me pasting the result into a webmail and inviting my corespondent to reverse the process.
Sending an encrypted file as an attachment to a webmail would also work.

R

---

From: Nicholas Weaver <[email-masked]>
Date: Fri, 21 Mar 2014 08:53:53 -0700

> Sending an encrypted file as an attachment to a webmail would also work.

That is NOT encrypting in webmail.  That is using webmail to transport encrypted content.

Why you can NEVER do meaningful encryption to protect data at rest from the server in actual Webmail is that the "client" software is dynamically provided by the server you are trying to protect the data from!

This is the "hushmail" and "lavabit" problem.  Neither service is actually able to protect the data at rest from a warrant, because the data can always be accessed when the user logs in.  Hushmail choses to snitch content to law enforcement, lavabit shut down.

You can only do "at-rest" protection on the mail server with a client program.

---

From: Robin Wilton <[email-masked]>
Date: Fri, 21 Mar 2014 16:04:05 +0000

> That is NOT encrypting in webmail.  That is using webmail to transport encrypted content.

I was just exploiting the loophole you left me when you phrased it, originally, as securing "data at rest in the context of a webmail system", rather than "encrypting in webmail", as you phrase it now.

---

From: [email-masked]
Date: Fri, 21 Mar 2014 12:39:32 -0400

On Fri, Mar 21, 2014 at 06:00:04AM -0700, Nicholas Weaver wrote:
> 
> To reply with the obvious: It is IMPOSSIBLE to secure data at rest
> in the context of a webmail system: server control can always enable
> accessing of all documents when the user logs in to check their
> webmail.

It all depends on what you mean by "encrypting data at rest".  It begs
the question of who has access to the keys.  For example, many hard
drives can do full disk encryption, and so it's relatively easy to set
up so the disk is encrypted when it is on the platter.  I do that for
the SSD in my laptop, for example.  I do have enter enter my password
when I power up my laptop, so if someone breaks into my machine while
I'm logged in, it won't provide any protection.  On the other hand, if
someone steals my laptop while it is powered off, it _does_ provide
protection.

You can also encrypt at the cluster/cloud file system level, so if
someone breaks into an individual GFS or Hadoopfs server (or more
importantly, the system administrators of the cloud file system), they
won't have access to the encrypted data.  But if the mail backend
server has the the encryption keys, then someone who breaks into the
webmail server, it won't necessarily help.

So in some sense, encrypting data at rest is actually pretty easy,
adding encryption to hard drive access generally doesn't introduce a
new bottleneck (where as adding encryption to web front ends or for
intra-data center communications can actually be more difficult on
that front).  If you are worried about NSA doing bulk surveillance,
protecting the web connections and and intra-data center communication
is actually far more difficult.

Regards,

						- Ted

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Mar 2014 14:10:40 -0400

On Mar 21, 2014, at 10:53 AM, Richard Barnes <[email-masked]> wrote:
> Which would you rather do, dig up a sub-sea cable, or tap a server admin on the shoulder?

Actually, they just put taps in Googles and Facebook's data centers.   No need to tap an undersea cable.   They even did it on the far side of SSL concentrators, where the traffic was flying unencrypted.   So encrypting traffic as Google is now doing certainly does address a meaningful threat model.

There are a lot of things you'd like your mail to do that can't be done if you don't trust the machine where the mail is stored.   If you want both security and features, you probably need to run your own server, or else you need some trust relationship with the service provider that likely isn't practical in a lot of cases, and isn't even _possible_ if your threat model is something on the level of not being victimized by NSLs.

---

From: [email-masked]
Date: Fri, 21 Mar 2014 17:57:39 -0400

TL writes:
 > There are a lot of things you'd like your mail to do that can't
 > be done if you don't trust the machine where the mail is stored.
 > If you want both security and features, you probably need to run
 > your own server, or else you need some trust relationship with the
 > service provider that likely isn't practical in a lot of cases,
 > and isn't even _possible_ if your threat model is something on the
 > level of not being victimized by NSLs.

One might suggest never sending the same message twice.  Why?
Because sending it twice, even if encrypted, allows a kind of
analysis by correlation that cannot otherwise happen.  Maybe that's
too paranoid, so let's back off a little.  One might suggest that
the individual or the enterprise that outsources its e-mail to a
third party thereby creates by itself and for itself the risk of
silent subpoenas delivered to their outsourcer.  If, instead, the
individual or the enterprise insources its e-mail then at the very
least it knows when its data assets are being sought because the
subpoena comes to them.  Maybe insourcing your e-mail is too much
work, but need I remind you that plaintext e-mail cannot be web-bugged,
so why would anyone ever render HTML e-mail at all?

The above is an excerpted paragraph from my speech to the RSA Conf
on 28 Feb, meaning nothing more than that I'm on the record.

  We Are All Intelligence Officers Now
  http://geer.tinho.net/geer.rsa.28ii14.txt

--dan

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 21 Mar 2014 22:21:59 +0000

> Best is the enemy of good enough.   To compromise your mail on the server, they have to compromise the server.   To compromise it in flight, they just have to tap the network.

But what we know of access to email and other information is that “they”, whether identified as NSA or random other governments, hack the server.

This sounds like a matter of looking where one is thinking about. There’s an old story that exemplifies it well. A passerby tries to help a drunk find his keys. The drunk is looking near a street lamp. Asked where he was when he lost them, he points down a dark alley. “Why are you looking here?” “The light is so much better”…

Encrypting data in flight is a good thing. Encrypting data in flight end to end is a better thing. If you’re trying to encrypt it where “they” look at it, you need to think about encryption at rest. Reason? Per reports, that’s where they look at it. China broke into various companies’ computers, as did the NSA.

I find this whole discussion minorly inane. Yes, encryption is a good thing, and yes, after however-many-years of talking about it, I’d like to see it done. The problem that brought this up, the Snowden reports, was that the NSA (and the EU) were accessing *metadata*. 

Wouldn’t it be interesting to solve the problem at hand rather than the one we think we might already know how to solve?

---

From: [email-masked]
Date: Fri, 21 Mar 2014 18:39:24 -0400

On Fri, Mar 21, 2014 at 10:21:59PM +0000, Fred Baker (fred) wrote:
> 
> Encrypting data in flight is a good thing. Encrypting data in flight
> end to end is a better thing. If you’re trying to encrypt it where
> “they” look at it, you need to think about encryption at
> rest. Reason? Per reports, that’s where they look at it. China broke
> into various companies’ computers, as did the NSA.

China has broken into systems to steal trade secrets, including
allgedly, fairly detailed copies of the F-35 Joint Strike Fighter.
But I'm not aware of any reports where China has broken into webmail
servers.  They have hacked the login username/passwords of various
activsts and used to to steal their e-mail, but that's a somewhat
different thing.

Similarly, I'm not aware of any published reports, including coming
from the Snowden revelations, which detailed NSA breaking into
servers.  They are spying on unencrypted communication data servers,
and they have been impersonating servers at Facebook and Google,
thanks to the deplorable nature of our CA architecture and the
security of CA issuers, but that's a somewhat different thing.

Yes, some of these problems can be solved if the users do end-to-end
encryption using tools like GPG or S/MIME.  However, the usability of
such systems is pretty horrible.  Fixing this is fundamentally much
more of an implementation issue than a protocol issue, so it's not
clear to me how much the IETF can do to improve things in terms of
user controlled end-point encryption.

> I find this whole discussion minorly inane. Yes, encryption is a
> good thing, and yes, after however-many-years of talking about it,
> I’d like to see it done. The problem that brought this up, the
> Snowden reports, was that the NSA (and the EU) were accessing
> *metadata*.

When the NSA was impersonating Yahoo servers, to capture video from
web chats and impersonating Facebook and Google servers, the NSA was
capturing *data*, not just *metadata*.

It's important to remember than when the NSA says, "we're only
capturing metadata under the authorities <FOO>", remember that that
says absolutely nothing about what they might be doing under some
other authority that they might have.  They are as slippery as a
crooked lawyer....

						- Ted

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 21 Mar 2014 23:09:11 +0000

Hi Fred,

On 03/21/2014 10:21 PM, Fred Baker (fred) wrote:
> Wouldn?t it be interesting to solve the problem at hand rather
> than the one we think we might already know how to solve?

You're correct. Unfortunately, for mail, despite decades of work
on e2e security we are no nearer to a technology that is likely to
be very widely used/deployed. I wish that were not the case, but
it is. And that's the case for fairly well understood reasons that
were rehearsed on this list late last year. (Can't recall when,
sorry.)

At the same time, I'd encourage those brave enough to be working
on that problem to keep at it - one of you will probably get right
eventually.

S.

---

From: Tim Bray <[email-masked]>
Date: Fri, 21 Mar 2014 16:17:37 -0700

Slightly off-topic, but there’s this thing called keybase.io that is doing
what feels like a pretty good job to me of wrapping up GPG in a palatable
UI (web & command line) with a key directory so that while I, for example,
have never taken the trouble to install E2E encryption in my mail, I can
see using keybase to encrypt particularly sensitive stuff.  Don’t know if
they’ve got just the right set of features, but it feels like there’s an
80/20 point lurking out there somewhere.  My blog on the subject is (I
hope) an OK introduction:
https://www.tbray.org/ongoing/When/201x/2014/03/19/Keybase

On Fri, Mar 21, 2014 at 4:09 PM, Stephen Farrell
<[email-masked]>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hi Fred,
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
>
> iQEcBAEBAgAGBQJTLMaUAAoJEC88hzaAX42iyYQIAL4Zagr3yBqUcnQxXnJ3k0A3
> cYzO7e3yV9nfD+jLgvj42CWffRYLe9mqEbHfwljNgURPkMx0CXwDafHje6Zm6uaf
> kuiguIHxqLu9AAuifLiQl2e9KsTHo9DRHjP+VuUU4tSxjEWbZ05PjT7iW8JiXBZp
> IYFABgF47exxyAjhl4a1W4ylqkpwDODFDXMTg+yhJCkNr4uDlF4zlWL2r90P57Wl
> dmXuD7p58Zm3tXx7tjAFwSp4nyzmtCX6Qftk+1kZRvbPIEFjNa6vzZgAhlN8DNPN
> qkzcVkw9WBREkm12f0yevnRp6zskvlMgQYAa29U8sGSEln8X9HJy7iLulBFTe9A=
> =wRap
> -----END PGP SIGNATURE-----
>

---

From: SM <[email-masked]>
Date: Fri, 21 Mar 2014 17:52:11 -0700

Hi Ted,
At 11:10 21-03-2014, Ted Lemon wrote:
>Actually, they just put taps in Googles and Facebook's data 
>centers.   No need to tap an undersea cable.   They even did it on 
>the far side of SSL concentrators, where the traffic was flying 
>unencrypted.   So encrypting traffic as Google is now doing 
>certainly does address a meaningful threat model.

"We" did that because you left that window open [1]. :-)  Time will 
tell whether the (new) threat model is a good one or not.

>There are a lot of things you'd like your mail to do that can't be 
>done if you don't trust the machine where the mail is stored.   If 
>you want both security and features, you probably need to run your 
>own server, or else you need some trust relationship with the 
>service provider that likely isn't practical in a lot of cases, and 
>isn't even _possible_ if your threat model is something on the level 
>of not being victimized by NSLs.

Even if you run your own server you might still have to trust some 
body.  I would not use the word "victimized" for NSLs [2].  There 
were papers published in 2009 in which subpoena threats were 
mentioned.  A threat model which only considers data in flight does 
not qualify as a threat model.

Regards,
-sm

1. 
http://entertainment.guardianoffers.co.uk/csp/nmp/products/medium/AA_RM001699.jpg
2. 
http://www.washingtonpost.com/wp-dyn/content/article/2007/03/20/AR2007032000921.html

---

From: Scott Brim <[email-masked]>
Date: Sat, 22 Mar 2014 07:34:17 -0400

On Mar 21, 2014 6:22 PM, "Fred Baker (fred)" <[email-masked]> wrote:
> Wouldn't it be interesting to solve the problem at hand rather than the
one we think we might already know how to solve?

I interpret this as "Look, at least we're making progress on something." I
doubt this lowers the feeling of urgency for other proven vulnerabilities.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Sun, 23 Mar 2014 00:45:07 +0000

On Mar 21, 2014, at 11:10 AM, Ted Lemon <[email-masked]> wrote:

> Actually, they just put taps in Googles and Facebook's data centers.   No need to tap an undersea cable.   

http://www.reuters.com/article/2014/03/22/us-usa-security-china-nsa-idUSBREA2L0PD20140322

---

From: Ted Lemon <[email-masked]>
Date: Sat, 22 Mar 2014 21:03:01 -0500

> http://www.reuters.com/article/2014/03/22/us-usa-security-china-nsa-idUSBREA2L0PD20140322

Did I say somewhere that nobody ever hacked any servers in a data center?   No, I did not.   I said that one of the hacks that was used, in a context where they didn't hack servers in a data center, was to install taps on the networks of service providers.

This is a real thing that happened, and securing those links is of real benefit.   By itself it doesn't solve the whole problem, but if you don't secure the messages in transit, then securing them on the server doesn't either.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 25 Mar 2014 13:11:55 -0400

There is a thoughtful critique of keybase.io here:

http://blog.lrdesign.com/2014/03/thoughts-on-keybase-io/

I have 2 invites left if you'd like to try it out (preference will go
to those of you I know (in the biblical key-signing sense) or have met
in person).

I do think it is a clever take on PGP user experience... there are a
few red flags, such as (optionally!) storing an encrypted copy of your
private key on their server. yikes.

best, Joe

On 3/21/14, 7:17 PM, Tim Bray wrote:
> Slightly off-topic, but there?s this thing called keybase.io 
> <http://keybase.io> that is doing what feels like a pretty good job
> to me of wrapping up GPG in a palatable UI (web & command line)
> with a key directory so that while I, for example, have never taken
> the trouble to install E2E encryption in my mail, I can see using
> keybase to encrypt particularly sensitive stuff.  Don?t know if
> they?ve got just the right set of features, but it feels like
> there?s an 80/20 point lurking out there somewhere.  My blog on the
> subject is (I hope) an OK introduction:
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> 
> Hi Fred,
> 
> You're correct. Unfortunately, for mail, despite decades of work on
> e2e security we are no nearer to a technology that is likely to be
> very widely used/deployed. I wish that were not the case, but it
> is. And that's the case for fairly well understood reasons that 
> At the same time, I'd encourage those brave enough to be working on
> that problem to keep at it - one of you will probably get right 
> eventually.
> 
> S.
> 
> _______________________________________________ perpass mailing
> list [email-masked] <mailto:[email-masked]> 
> _______________________________________________ perpass mailing
> list [email-masked] 

- -- 
Joseph Lorenzo Hall
Chief Technologist
Center for Democracy & Technology
1634 I ST NW STE 1100
Washington DC 20006-4011
(p) 202-407-8825
(f) 202-637-0968
[email-masked]
PGP: https://josephhall.org/gpg-key
fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Pranesh Prakash <[email-masked]>
Date: Thu, 27 Mar 2014 14:02:43 +0800

Joseph Lorenzo Hall <[email-masked]> [2014-03-25 13:11:55 -0400
> to those of you I know (in the biblical key-signing sense) or have met

Me me!