Re: concrete steps for improving apt downloading security and privacy
On Sat, Jul 5, 2014 at 12:43 AM, Lou RUPPERT <himself@louruppert.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Joel Rees:
>> On Fri, Jul 4, 2014 at 11:44 AM, Hans-Christoph Steiner
>> <hans@at.or.at> 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.
Reply to: