Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)
Adrian Bunk <firstname.lastname@example.org> writes:
> 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.
Both of those were also in the category of things that I think are
unlikely attacks unless the government is specifically targeting you, so
that leaves me confused by what point you're trying to make here.
For the record, MITM with a fake certificate is certainly realistic for a
targeted attack, and is something that one has to think about. There's a
reason why certificate pinning is a standard part of the defenses in a
higher-security SSL configuration. I do agree (and in fact this was my
whole point) that it's unlikely a government would burn their certificate
capability this way just to figure out what Debian packages you're
> I would assume this can be pretty automated, and that by NSA standards
> this is not a hard problem.
Since the entire exchange is encrypted, it's not completely trivial to map
size of data transferred to a specific package (of course, it's even
harder if we reuse connections). But the point I'm making is more that
it's not something that just falls out of an obvious surveillance
technique that has wide-ranging uses. It requires someone to write code
to *specifically* target Debian mirrors, which I think is much less likely
than just collecting all the data and deciding to analyze it afterwards.
(That said, it would be possible to reconstruct the necessary data to do
the analysis later, I suppose. But here too someone has to care at a
level deep enough to go write code to do it, as opposed to just doing ad
> 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?
I disagree that either of them is a solution. They're both mitigations,
and if a nation-state attacker is targeting you specifically, I wouldn't
want to rely entirely on either of them.
I agree with you that Tor is a stronger mitigation.
Tor is easier for us as a project, since we don't really have to do
anything (assuming we just rely on existing exit nodes). SSL is much
harder for us as a project, but is simpler for the end user (and doesn't
require them to take a stance on the merits of Tor as a project; I don't
really want to get into a philosophical argument about the merits of
Internet anonymity, but this is not something everyone thinks is an ideal
to strive for as opposed to a situational fix for very specific risks).
In an ideal world we'd offer both.
> 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.
This is true. But the set of problems are largely independent. While
solving the download side doesn't fix all the other problems, it also
doesn't interfere with fixing all the other problems, and is still needed
to make the overall system more secure.
The reason why addressing the download side is appealing to me is that we
know dragnet surveillance is common and ongoing, so the risk it's
addressing is tangible and we have some reasonably solid information about
how it works. So while it may not be the most serious problem, it's one
of the problems we understand the best, and therefore are in a good
position to do something about.
> 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.
I'm a great believer in ubiquitous encryption, even if it seems silly,
just on the grounds of "why not?". We should encrypt reportbug traffic
too, if we can. Yes, a lot of the details get exposed at the other end
anyway (although not necessarily), but it's usually fairly trivial to
encrypt links, and if it is, there's basically no reason not to.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>