Adrian Bunk <b...@stusta.de> 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 downloading, though. > 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 hoc queries.) > 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 (r...@debian.org) <http://www.eyrie.org/~eagle/>
