Adrian Bunk <b...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/>
