Re: concrete steps for improving apt downloading security and privacy
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.
> 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!"
> 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.
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?
I suppose, if I'm looking for shoes for my wife's birthday, and it's
supposed to be a surprise, and she regularly analyzes the house's
router logs to check whether the kids are going to pornofthemonth.xxx,
..., but that's not the wireless router, come to think of it. Does
your wife check your router logs? Okay, I suppose my son might, but,
seriously.
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?)
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.
> 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.
> > 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?
"Content creators" and site managers probably want a tool that will
highlight or red-circle elements on a page that are declared
plaintext, and (as a different option or command) elements that will
end up plaintext when the page is sent TLS. And they want the tool to
walk their site automatically, leaving a log behind.
Users want their browser to tell them when parts of the data in the
query they send TLS are going to be sent plaintext. Some may want to
know which elements are going to be sent plaintext. Some may want to
scan for plaintext elements before they start filling in the form, so
they don't waste their time. But they don't really care if the picture
of the shoe or its title is being received plaintext. Such information
is perceived as noise, unless they really are concerned about the off
chance that someone might be capturing their data stream to find out
what pictures or political rants they are accessing.
> >> 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?
> 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.
> 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?
> > 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?
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.
And, again, just because "everyone" is doing it, we don't have to add
to the pot of raw material. Quite the contrary, if somebody stands up
and says, we aren't doing that, those who are doing the lemming trick
sometimes sit up and take notice.
> >>> 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.
All it takes is one backdoor to start monitoring a famous person's surfing.
> >> 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?
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.
What they won't do is risk tipping their hand by posting compromised
binaries for just anyone to pick up. The data they are gathering is
quite valuable, or at least they think it is, and if anyone noticed
the compromised binary, they would lose their data source. Carefully
targeted attacks and data gathering.
Reply to: