Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)
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.
Security is both technical and politics, and on the political side,
actively doing something is much riskier. Nation-state surveillance teams
are generally not fond of headlines, and there are political consequences
to being caught with your hand in the cookie jar. Therefore, technical
measures that force them to take an *active* measure to get data, as
opposed to just passively tapping and siphoning data, are, in practice,
quite effective. Not because they don't have the technical capabilities
to do that, but because it's much riskier politically to do so, and often
that risk isn't worth the reward from their perspective.
It's true that tapping a single mirror could still be passive, but it's a
much trickier kind of passive than just snooping on a cable. They have to
be passively collecting the actual server logs in some way, which means
presence on the box or access to some network where those logs are being
sent in the clear. That does raise the bar substantially.
> Debian would accept debian.nsa.gov as mirror, and the NSA might already
> operate or have access at some current mirrors.
I'm a little dubious that this is true (I would recommend against it), but
even if so, Debian could also easily revoke that acceptance at any point
if we decided we were uncomfortable with it, which makes it an unreliable
way to gather this sort of data.
> 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.
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.
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.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: