Re: concrete steps for improving apt downloading security and privacy
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Joel Rees:
> 2014/07/07 11:32 "Lou RUPPERT" <himself@louruppert.com>:
>>
>> -----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.
>
> Why? By the time you're looking at it, there's nothing to do about
> what has been sent in the clear.
There are sites now which have dynamic content. Imagine a site like
Facebook, where there is so much content that it can't even fit on one
page! As I already explained, the cleartext download warning isn't
warning you about the data you're already looking at; it's warning you
that the mechanism you're trusting may not be trustworthy. It's
telling you "stop now unless you understand the problem." Advice I'd
recommend!
>> 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.
>
> https is not a flag for "TOP SECRET NSA PLAN FOR BACKDOORING THE
> UNIVERSE'S COMPUTERS OHS NOES!"
Not following you here.
>> It means a breach is potentially occurring and that I should stop
>> what I'm doing if the information presented is sensitive.
>
> Most of what is sent https is not even classified sensitive.
Agreed.
> If I'm looking at a catalog page from a shoe store on my table,
> connected via the phone network, getting close to my 2G cap for my
> wireless router for the month. My battery's getting low. Do I want
> to waste bandwidth and CPU cycles for TLS encoding, just for
> pictures of shoes?
Let's try to turn our focus back to the question at hand, which is
whether there are merits to promoting https mirrors for users who have
concerns about being watchlisted based on their software choices. I
think client cpu cycle and bandwidth concerns are a bit of an
anachronism these days anyway.
> Oh, I suppose, if I were the kind of person to go to porn sites, I
> might decide not to return to such a site that sent me it's baaaad
> pics plaintext. (Did you know that encrypting a picture sometimes
> results in a picture that looks like it has been through a random
> color-permuting filter?)
That's only if you don't include it inside of a stream with a bunch of
other content, like http 1.1, for instance.
> Of course, if someone is tapping my stream and looking at the
> images I'm looking at, they probably also know what sites I'm
> connecting to.
How about this scenario: Someone is installing software from a
software catalog from a country where downloading software isn't
illegal, but where people who download certain software are flagged as
terrorists and made to undergo certain invasive scrutiny as a result.
One catalog has the page served via https, but the software served via
http, because they haven't upgraded their servers in a couple decades,
and they own a lot of stock in the electric company.
The other catalog has the whole content served via https.
Which catalog do you think can install something like 'tor' without
the user being watchlisted? Now update the scenario for an environment
in which the nation state has a DPI border firewall and automatically
stops downloads of certain software they don't like. Which catalog do
you think will result in the user being able to successfully download
what they need?
(an interesting side effect from this is that the DPI site may decide
to block the entire TLS-only catalog because of the lack of
introspection, so maybe defaulting to an https mirror may have
unintended consequences in such an environment?)
>> What I don't want is a site that claims to be 'secure' while
>> leaking.
>
> Every site leaks. "Secure" pages that are blanket-sent TLS for the
> wrong reasons will not be analyzed for leaks, because the people
> who design the sight are unaware that TLS is not a big enough
> blanket.
Explain, please?
>>>> 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?
>
> Surely you see that is not all that we are talking about?
Nope. So what is the risk you're talking about, if not some key
factoring plot?
>> If they want to perfect some secret squirrel factoring technique,
>> there are plenty of popular candidates to use.
>
> So, give them more data. Give them more of the hard data, in fact.
Why encapsulate anything static in TLS then, by that logic? We've
already stated the case where someone may want to hide which binaries
they're downloading. That problem can be practically solved by
offering a TLS option.
>> We don't need to worry about debian repos becoming the key that
>> allows them to develop that technique.
>
> Really? I mean, the current encryptions will be broken sooner or
> later. You're voting for sooner?
No, I'm voting to trust the math, until someone can prove otherwise.
>>> 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.
>
> Do you have any idea how much keyboard/disk/NIC activity it takes
> to generate 256 bits of truly random data?
That's not the problem being solved by that. Do some reading on
entropy, and you'll see why mixing and multiple sources is important
when you can't trust any one source completely. But again, let's stick
to the issue we're discussing.
> But again, that's only half the story. When you send a kernel
> image encrypted, they have the plaintext and the crypt, and the
> thing is large and hard. This is the kind of data that can be used
> to completely break an entire encryption algorithm.
No, they have *part* of the plaintext and a crypt whose keys have been
negotiated specific to that interaction between client and server.
>>>>> 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.
>
> For you and me, yes. To a certain extent, the movie plots are
> unreal even for valuable targets. But if they could get a MIM
> attack set on certain famous people, we would definitely expect
> them to. Especially if they think they can impose the MIM on a
> small enough segment of the internet for a short enough time that
> no one would notice.
So that's more realistic to you than the confirmed program to flag
users who download certain verboten software?
> All it takes is one backdoor to start monitoring a famous person's
> surfing.
Indeed. But my point is that a yet to be disclosed flaw in TLS is
probably not anywhere on the top ten likely scenarios for how that
backdoor is going to be introduced. Meanwhile there are problems which
TLS could arguably solve.
>> 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?
>
> Why would we need to suppose such a thing? It's a safe assumption
> that it is already occurring, probably including some of the https
> mirrors.
No it isn't. A safe assumption is that state level entities are
obtaining certs via vulnerable systems (hello heartbleed), social
engineering, or overt collusion. An unsafe assumption is one where we
throw out a useful security control based on panic and an incomplete
understanding of http/tls.
- --
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-----
iEYEAREKAAYFAlO7G/0ACgkQEn9NahFdz2JvkQCeJhMp+DciS8Dw3cvH5fJVT9Vz
4MAAn0rWE4RhFUesuSQNH4e5cWiqwQ6s
=lk9z
-----END PGP SIGNATURE-----
Reply to: