Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)
On Mon, Oct 24, 2016 at 09:22:39AM -0700, Russ Allbery wrote:
> Adrian Bunk <bunk@stusta.de> writes:
> > On Sun, Oct 23, 2016 at 07:28:23PM -0700, Russ Allbery wrote:
>
> >>...
> >> The value of HTTPS lies in its protection against passive snooping. Given
> >> the sad state of the public CA infrastructure, you cannot really protect
> >> against active MITM with HTTPS without certificate pinning.
>
> > You are implicitely assuming that mirrors can be trusted,
> > and even that is not true.
>
> > Who is operating ftp.cn.debian.org, and who has access to the logfiles
> > on that server?
>
> So, here, I think you're making the best the enemy of the good, which is
> always tempting in security.
>
> Everyone (myself included) wants to create a system that's actually
> secure, the same way that we want to create software that works properly.
> But in security, even more so than most software, that's rarely possible.
> There's always another attack. It's a sliding scale of tradeoffs, and
> just because you're not preventing all attacks doesn't mean that making
> things harder for the attacker isn't useful.
>
> Looking at this worry in particular, note that you're now assuming that a
> nation-state has compromised a specific mirror (in some way, maybe just by
> running it without regard to the privacy of its users). As pointed out,
> this only gets partial information, but more importantly, this requires
> the nation-state to actively do something. They have to now either
> compromise the mirror or be running it in a way that may be discoverable.
>...
The government operating or having access to the mirror you are using is
a lot more realistic and easier than the MITM with a fake certificate
you were talking about.
> > When a nation-state actor analyzes all the traffic on a network
> > connection that also happens to carry the traffic between you and the
> > Debian mirror you are using, HTTPS won't make a difference.
>
> Well, I disagree, largely because I think you're overestimating the
> willingness to do deep data analysis on something that's only a tertiary
> (at best) security objective.
>
> Dragnet surveillance is the most common nation-state approach at the
> moment primarily because it's *really easy*. Get a backbone tap
> somewhere, dredge all the unencrypted data, run simple analysis across it
> (pulling out URLs accessed is obviously trivial for unencrypted HTTP),
> throw it into some sort of huge database, and decide what you want to
> query for later.
Pulling out the dates and amounts transferred fot HTTP traffic is
also trivial.
> Doing traffic analysis that requires analyzing encrypted data by object
> size or the like is still certainly *possible* (that was the point that I
> made in my first message to this thread), but it's not *trivial*. It
> requires someone go write code, go think about the problem, and regularly
> gather information from a mirror to correlate encrypted object sizes with
> packages. It requires a *human* actually *think* about the problem, and
> then set up and maintain an automated system that requires some level of
> ongoing babysitting.
I would assume this can be pretty automated, and that by NSA standards
this is not a hard problem.
> Can nation-states do this? Obviously, yes. But the goal here isn't to
> prevent them from launching these sorts of attacks. The goal is to make
> it expensive, to require that they justify a budget to hire people to do
> all this additional work that requires custom automation, and to raise the
> bar across the board to make simplistic dragnet surveillance unrewarding.
> This forces them into making some hard decisions about resource allocation
> and attempting more visible intrusions. Hard decisions are expensive, not
> just in resources but also in politics.
>
> It *is* a tradeoff, not perfect security, so we should obviously also take
> into account how much effort it takes on our side and whether we're
> expending less effort than we're forcing from our adversary. But, in
> general, ubiquitous encryption is totally worth it from that sort of
> effort analysis. Once you get good systems in place (Let's Encrypt
> seriously changed the calculation here), adding encryption is usually far
> easier than the work required on the snooping side to recover the sort of
> metadata they had access to unencrypted. I think that's the case here.
Let me try to summarize my point:
apt-transport-https makes it slightly harder to determine what packages
are being transferred, and this is good.
When someone is seriously worried about a nation-state actor determining
what packages he downloads then apt-transport-https is not a solution,
and the proper solution is apt-transport-tor.
I assume you will disagree regarding the word "slightly".
Are we in agreement regarding the rest of my summary?
When someone is worried about the confidentiality of the information
what packages are installed on a system, only looking at the download
side is also missing other areas that might be even more problematic.
I would be a lot more worried about what reportbug does when a package
suggests libdvdcss2 - in some jurisdictions this might just be enough
when the government is looking for a reason to raid your home.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: