Re: concrete steps for improving apt downloading security and privacy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Joel Rees:
> 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:
> 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.
Not true. If I'm looking at an https-enabled page, and elements
included in the page are http-only, I want to know about it. It means
the site maintainer messed up, and potentially sensitive information
is going in the clear despite being included from a web page that is
https. It means a breach is potentially occurring and that I should
stop what I'm doing if the information presented is sensitive. What I
don't want is a site that claims to be 'secure' while leaking.
> 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.)
Huh?
>> 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.
We're talking about datasets used to factor keys, right? If they want
to perfect some secret squirrel factoring technique, there are plenty
of popular candidates to use. We don't need to worry about debian
repos becoming the key that allows them to develop that technique.
> 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.
Yes, but except for freebsd's(?) mistake of using it exclusively,
you'll find that OSes mix the entropy sources when providing
/dev/random, and that most processes use a derivative PRNG in
/dev/urandom. If you look at the Linux /dev/random implementation,
you'll find that a busy site will provide enough noise to reduce the
impact of a compromised hwrng. People who care about entropy obtain it
from a variety of sources.
>>> 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?
Factoring/brute-forcing the debian signing keys so that they can
simulate debian mirrors when MITMing some poor hapless target is a
movie plot threat.
>> 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.
OK so supposing the NSA offers its own mirror. The package
installation process verifies PGP signatures. What is the actual
scenario you're trying to prevent?
- --
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-----
iEYEAREKAAYFAlO6Bn0ACgkQEn9NahFdz2L8kwCgsWX6ldGGzIs2EOMt6vn3KEza
KKEAoMvDjTUv9tCO+6vNVOOYo0J07EAm
=YzvF
-----END PGP SIGNATURE-----
Reply to: