Re: concrete steps for improving apt downloading security and privacy

[Joel Rees]

On Sat, Jul 5, 2014 at 6:14 AM, Hans-Christoph Steiner  wrote:
>
> [...]
> I'm with Lou on this one,

I'm not surprised.

> there are already much bigger and better data sets
> for that.

So we should give them even more?

> According to this paper[1], Fedora 11+, Red Hat, SUSE, Google
> updates like Chrome and Android tools, Adobe AIR, Firefox, Python pypi, and
> others all use HTTPS for their updates.

Pardon me for being obnoxious, but do you really need to refer to
someone else's research[1] for that little gem?

Well, I suppose, if we were on the user list, we might assume that
some of those participating might not be using those tools, or might
not be noticing what they are downloading. In which case, it would be
nice, if you were assuming such, to provide a
page/paragraph/table/etc. number, such as

Table 2, found in section 5, on p. 5 of


(Or of .
I guess the reason you gave me two links to the same paper is so that
if one is unreachable we might be able to get to the other?)

>  Debian is behind the curve here,

So we aren't fashionable?

> HTTPS for updates is becoming the norm.

Lemmings, everyone?

> Plus if the HTTPS it set up with
> "Forward Secrecy" ciphers, the keys are frequently rotated.

The MacGuffins?

But what is the Holy Grail for them? (Yeah, Holy Grails are also
MacGuffins, but keys are red herring-style MacGuffins here.)

> And on the flipside of Joel's argument, right now, the NSA tries to store as
> much encrypted data as possible.

They admit as much.

> That way when they get the key later, they
> can go back and decrypt old traffic.

Do we really think that's the only reason they store it?

> So generating more HTTPS traffic means
> they can't keep up as much.

Hmm. I wonder which they are going to have an easier time budgeting --
adding more off-line storage or adding more on-line CPUs+storage? You
do understand that emulating distribution networks takes CPUs?

> But this is probably not really important in this
> case since they would probably notice that the sites are mirrors and ignore
> the traffic.

???

> .hc
>
> [1] http://freehaven.net/~arma/tuf-ccs2010.pdf  or
> https://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf
>



-- 
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAAr43iPovcP-xFj+RKJfeGh4u+YgYKRdRRFEkuw9o9hzAoj=l...@mail.gmail.com

Re: concrete steps for improving apt downloading security and privacy

[Joel Rees]

On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Joel Rees:
>> On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner
>>  wrote:
>>>
>>> [rhetoric encouraging the use of TLS transport for mirrors] [list
>>> of current https mirrors]
>>
>> Far be it from me to argue with ucalgary.ca, but one thing that
>> bothers me about using TLS as a download transport is that, if I
>> were the spooks, and I wanted a huge sample of crypts from a known
>> plaintext, I could think of worse ways to go than to get the
>> opensource crowd to provide them for me.
>
> Any popular site with relatively static content would do that.

And you know, the funny thing is that MSIE took to "warning" people
when there was a mix of encrypted and unencrypted data on a page. How
long ago? Yeah, I know, it was so they could display that red herring
of a lock for "secured pages".

You don't need a warning when you are looking at un-encrypted data.
You only need a warning if you are _sending_ un-encrypted data. See
how Microsoft has been complicit in this particular social engineering
scheme from a long time ago? (I thought, back then, that they were
just being lazy or trying to meet a stupid market window with
incomplete tech again. Naive of me, yes.)

> Apple
> store or Play store would probably provide a more useful dataset for
> them anyway.

But not so interesting, and not so "constant". Sure, enough bits and
pieces are separable to extract much of the constant part, but I don't
think it's very interesting to the spooks. I mean, I think they
already have what they need there pretty early on.

> But if you configure it and the clients to favor
> ephemeral keys you reduce the usefulness of captured traffic in being
> able to simulate the server itself.

And give them even more to work from. Sure.

I mean, yes, they are trying various ways to find the keys people are
using, but those aren't the big fish. Especially since we have to
assume that the hardware "entropy" generators in the CPUs for the most
popular CPUs are pretty much under the control of one set of spooks or
another.

>> I mean, yeah, they probably have the resources to simulate the
>> debian download infrastructure in their internal server farms, but
>> why do their work for them and free their resources up for other
>> jobs?
>
> I'm not sure that's a realistic scenario.

Why not?

>> Especially when the only real advantage of using TLS download
>> transport is (the illusion of) being able to download what you
>> want without "them" knowing exactly what you downloaded.
>
> Yeah they could probably infer it based on the session size.

Uhm, yeah, that's another trick they have available. But in many
cases, they don't even need to do that.

> They do
> that for other encrypted streams, like determining successful SSH logins.
>
> But TLS also serves as a sort of sloppy authentication mechanism,
> assuring you that someone someplace has vouched for the fact that
> you've connected to the system you intended to connect to. It's not
> terribly useful when you already sign your packages, but layers etc.

I myself use the argument of added low walls and speed bumps when we
are talking about skript k!dd13s, but low walls are not such a
wonderful strategy when we turn our attention to professionals. It's
pushing a metaphor, but a low wall can sometimes be another place for
a spook to hide.

As someone pointed out, verifying the mirror we've connected to is not
useful when we don't particularly have, or want, a way to prevent a
spook-owned mirror from joining the pool.

-- 
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caar43iotff6hdoy7es4pv2jpjcw5zveukfcgpkhrk_n2e+1...@mail.gmail.com

Re: concrete steps for improving apt downloading security and privacy

[Hans-Christoph Steiner]

On 07/04/2014 11:43 AM, Lou RUPPERT wrote:
> Joel Rees:
>> On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner
>>  wrote:
>>>
>>> [rhetoric encouraging the use of TLS transport for mirrors] [list
>>> of current https mirrors]
> 
>> Far be it from me to argue with ucalgary.ca, but one thing that 
>> bothers me about using TLS as a download transport is that, if I
>> were the spooks, and I wanted a huge sample of crypts from a known 
>> plaintext, I could think of worse ways to go than to get the 
>> opensource crowd to provide them for me.
> 
> Any popular site with relatively static content would do that. Apple
> store or Play store would probably provide a more useful dataset for
> them anyway. But if you configure it and the clients to favor
> ephemeral keys you reduce the usefulness of captured traffic in being
> able to simulate the server itself.
> 
>> I mean, yeah, they probably have the resources to simulate the
>> debian download infrastructure in their internal server farms, but
>> why do their work for them and free their resources up for other
>> jobs?
> 
> I'm not sure that's a realistic scenario.
> 
>> Especially when the only real advantage of using TLS download 
>> transport is (the illusion of) being able to download what you
>> want without "them" knowing exactly what you downloaded.
> 
> Yeah they could probably infer it based on the session size. They do
> that for other encrypted streams, like determining successful SSH logins.
> 
> But TLS also serves as a sort of sloppy authentication mechanism,
> assuring you that someone someplace has vouched for the fact that
> you've connected to the system you intended to connect to. It's not
> terribly useful when you already sign your packages, but layers etc.

I'm with Lou on this one, there are already much bigger and better data sets
for that.  According to this paper[1], Fedora 11+, Red Hat, SUSE, Google
updates like Chrome and Android tools, Adobe AIR, Firefox, Python pypi, and
others all use HTTPS for their updates.   Debian is behind the curve here,
HTTPS for updates is becoming the norm.  Plus if the HTTPS it set up with
"Forward Secrecy" ciphers, the keys are frequently rotated.

And on the flipside of Joel's argument, right now, the NSA tries to store as
much encrypted data as possible.  That way when they get the key later, they
can go back and decrypt old traffic.  So generating more HTTPS traffic means
they can't keep up as much.  But this is probably not really important in this
case since they would probably notice that the sites are mirrors and ignore
the traffic.

.hc

[1] http://freehaven.net/~arma/tuf-ccs2010.pdf  or
https://isis.poly.edu/~jcappos/papers/samuel_tuf_ccs_2010.pdf



signature.asc
Description: OpenPGP digital signature

Re: concrete steps for improving apt downloading security and privacy

[Lou RUPPERT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Joel Rees:
> On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner
>  wrote:
>> 
>> [rhetoric encouraging the use of TLS transport for mirrors] [list
>> of current https mirrors]
> 
> Far be it from me to argue with ucalgary.ca, but one thing that 
> bothers me about using TLS as a download transport is that, if I
> were the spooks, and I wanted a huge sample of crypts from a known 
> plaintext, I could think of worse ways to go than to get the 
> opensource crowd to provide them for me.

Any popular site with relatively static content would do that. Apple
store or Play store would probably provide a more useful dataset for
them anyway. But if you configure it and the clients to favor
ephemeral keys you reduce the usefulness of captured traffic in being
able to simulate the server itself.

> I mean, yeah, they probably have the resources to simulate the
> debian download infrastructure in their internal server farms, but
> why do their work for them and free their resources up for other
> jobs?

I'm not sure that's a realistic scenario.

> Especially when the only real advantage of using TLS download 
> transport is (the illusion of) being able to download what you
> want without "them" knowing exactly what you downloaded.

Yeah they could probably infer it based on the session size. They do
that for other encrypted streams, like determining successful SSH logins.

But TLS also serves as a sort of sloppy authentication mechanism,
assuring you that someone someplace has vouched for the fact that
you've connected to the system you intended to connect to. It's not
terribly useful when you already sign your packages, but layers etc.


- -- 
I prefer encrypted email.  Get my key here:
http://www.louruppert.com/keys/115DCF62.asc
PGP Fingerprint: 3261 B9F9 9363 D512 56F8  12DD 127F 4D6A 115D CF62
-BEGIN PGP SIGNATURE-

iEYEAREKAAYFAlO2y64ACgkQEn9NahFdz2JUNQCgjZChVYQEwELRqLg7uweq86Ee
3IQAoKWjpfzBeTnHpoMbmfirx6N7oMDU
=F6xl
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/53b6cbae.4040...@louruppert.com

Re: concrete steps for improving apt downloading security and privacy

[Joel Rees]

On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner  wrote:
>
> [rhetoric encouraging the use of TLS transport for mirrors]
> [list of current https mirrors]

Far be it from me to argue with ucalgary.ca, but one thing that
bothers me about using TLS as a download transport is that, if I were
the spooks, and I wanted a huge sample of crypts from a known
plaintext, I could think of worse ways to go than to get the
opensource crowd to provide them for me.

I mean, yeah, they probably have the resources to simulate the debian
download infrastructure in their internal server farms, but why do
their work for them and free their resources up for other jobs?
Especially when the only real advantage of using TLS download
transport is (the illusion of) being able to download what you want
without "them" knowing exactly what you downloaded.

-- 
Joel Rees

Be careful where you see conspiracy.
Look first in your own heart.


-- 
To UNSUBSCRIBE, email to debian-security-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAAr43iOTxVcCGyh5+d4VA43279Np6cKm9=4sq-wl0a1v8j5...@mail.gmail.com