Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)
Adrian Bunk <bunk@stusta.de> writes:
> If I were looking at the apt traffic, the most interesting for me would
> be the traffic to security.debian.org that a computer running Debian
> stable usually produces.
> Just collecting the data when and how much HTTPS traffic is happening
> should be sufficient to determine information like the following:
> What Debian release is running on that computer?
> Which security relevant packages are installed in that computer?
> Are security updates downloaded automatically or manually?
> In the latter case, are they installed in a timely manner?
Again, this requires targeting. It requires someone go to the effort of
building the software that does this sort of analysis, and then keeping it
up-to-date with changes in the Debian archive structure, transport layer,
package sizes, etc. (And knowing whether the packages are installed is
quite a bit harder to figure out without doing more active things like
fingerprinting, and even then it's not always possible.)
> When your adversary is powerful enough that he is capable of monitoring
> your traffic with security.debian.org, then apt-transport-https is just
> snake oil.
So, I'm not quite sure how to put this, since I don't know how much work
you've done professionally in computer security, and I don't want to
belittle that. It's entirely possible that we have equivalent levels of
experience and you just disagree with me, and I want to acknowledge that.
But, that said, this feeling, which comes across roughly as "this doesn't
completely fix the problem, so why bother with half measures?", is a trap
I see people fall into when they don't have a good feel for the dynamics
of practical security measures. It's *so* tempting to let the best be the
enemy of the good because you, as an experienced engineer with a complete
mental model of the system being protected, can see flaws in the
protective mitigations and feel like it would be easy to counter them.
This is why, in computer security, it's usually a bad idea to talk about
"fixes" except for specific software-bug vulnerabilities. Security
measures are often described as "mitigations," and rather than determining
whether or not something is secure, it's usually better to talk about
making things easier or harder for an attacker.
You should generally assume that if a sufficiently funded and motivated
adversary wants to break into your Internet-connected system in
particular, they're going to succeed. But that doesn't mean that computer
security is useless. There are multiple other factors in play: a lot of
adversaries care a great deal about not being *detected* (which is a much
easier problem), most attacks are not targeted at all (they're either
spray-and-pray automated attacks or they're dragnet data gathering with no
predetermined goal in mind), and time and resources matter. To give a
specific example, there are many situations where you don't have to keep a
government out of your stuff permanently. You just have to keep them out
for long enough that you can get your lawyer involved.
In the specific case of retrieval of apt packages, use of HTTPS raises the
bar for the attacker who wants to know what packages you probably have on
your system from simply parsing the GET commands (information that would
be captured in any dragnet surveillance database as a matter of course)
for package names and versions to writing Debian-specific analysis code to
make (fallible) guesses from traffic analysis. This is a fairly
substantial change in the required resources, and makes various things
(such as retroactive data mining when this particular use case wasn't
anticipated in advance) considerably harder.
> The NSA might actually be very grateful that there are people who are
> promoting such snake oil as solution, since this lowers the probability
> of people looking for solutions that could make it harder for the NSA.
I truly don't believe this worry makes any sense.
Ubiquitous encryption makes things considerably harder for the NSA because
they have to expend more resources. There is substantial confirmation of
this from the hissy fits that the NSA has thrown in the past about public
use of encryption, and their repeated attempts to get people to adopt
crypto with back doors. I know some people think this is all an elaborate
smoke screen, but I think that level of paranoia is unjustified. The
people working for the NSA aren't superhuman. Encryption matters, even if
you can still recover metadata with traffic analysis.
Yes, you're not going to get absolute security against the NSA with cheap
wire encryption, but you *do* change the resource battle. The NSA can
bring almost unlimited resources to bear *on single, high-value targets*,
and those require substantially different precautions. But I'm just as
worried about the implications of huge databases of information about
people's on-line activities sitting in government databases. (I'm
actually somewhat less worried about what the nation-state that gathered
that data does with it, in most situations, than about what happens when
they don't secure it properly and it is acquired by some actor like
Wikileaks that is happy to use it to dox women in Turkey. Just to pick a
random example.)
Yes, if people treat security as a choose-one affair where using one
security measure means you're not allowed to add any other later, that
would be bad. So let's not do that. And that too is why it's important
to talk about security *mitigations*, to avoid giving the impression that
one is now absolutely secure and can stop thinking about attacks.
> By discouraging users from using mirrors for security.debian.org, Debian
> is presenting a nearly complete list of all computers in the world
> running Debian stable and their security update status and policies on a
> silver plate to the NSA.
It's a tradeoff with freshness of security updates. Personally, I usually
use an in-house mirror of security.debian.org for various reasons, and
it's worth noting that our "discouraging" isn't particularly aggressive.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: