On Sun, Oct 23, 2016 at 10:03 AM, Eugene V. Lyubimkin <jac...@debian.org> wrote: > Thank you for the long list of examples what could go wrong. I'm happy I > don't have urgent fixes to apply.
Well, I would say the privacy issues are rather concerning. Security is generally broken down into at least the following three categories: * Confidentiality (X) * Integrity (✓) * Availability (✓) Confidentiality is not a current default benefit out of the box with Secure APT. All choices of user software are exposed. You can even uniquely identify users by which unpopular packages they get updates for as they transition their laptop around to various networks. Availability is covered by the vast numbers of mirrors, so that is covered well. Integrity is presumed by the GPG / hash verifications. Sure, you have no publicly known vectors to fix. Presumably there are unknown vectors the NSA and others have developed, but not made public. There are really smart people out there that keep their vulnerabilities private for malintent. This is the concern with leaving clear pathways for exploitation via unencrypted HTTP channels. It is also highly likely that at least one member of the Debian security team has had / will have leaked a private GPG repo signing key, more than likely by unknown errors in operations or inadvertent actions. As such, without HTTPS, signing rogue release / package files for targeting a specific network can take place in secret (targeted organization would have to detect the tainting at their end-point). This is because the NSA could specifically target that network with a rogue "Entity-in-the-Middle" (EitM) attack using the stolen private key. If HTTPS+HPKP were utilized, it would make pulling off the attack much more costly, as now they would have to somehow get the mirrors the target network is using to sync rogue release / package files without anyone noticing (more easily detectable by mirror system admins). And I want to reiterate this attack: Given a global view of the Internet, the NSA could craft queries like: "Show us all German systems that originate from network ranges belonging to <insert-any-org-here> that have never requested a patch for <insert-any-vuln-here>" In the above example, they don't need to directly attack APT or Debian. They can automatically build up a database of CVE attacks that will work both remotely and locally against the organization, because they can see that the organization never installed those packages. This means the unencrypted nature of HTTP thus leaks your entire organizational security posture to government players for selective targeting. We know the NSA is doing this, from the Snowden revelations. See XKeyscore program for more info. There are other programs that specifically target Linux system administrators. So, just being on this list might actually put you into a NSA selector group for targeting as well (be warned, if you didn't already know). > 1) Checking chain (e.g. gpgv and its callers) have bugs. True, same as > checking layer for secure transports also have bugs. Agreed. Please let me know of a good test case to validate that your tools, which are not APT (?), are doing the right things. You said you maintained a tool which "downloads and validates Debian archives in a similar way APT does", which means not exactly the way APT does. Let me know the name of your tool and how to setup some test cases to validate your tool is doing things properly. Glad to spend some time on it and contribute any potential findings for the community benefit. > 1a) If an user downloads keys not via packages, downloading may go wrong. > True. If I use debian-archive-keyring, I'm fine. RIght, but there is a bootstrap problem for obtaining trusted keys in various circumstances though. The SecureAPT wiki even documents those and instructs the user to use out-of-band methods for obtaining the key [1], opening up such attacks. [1] https://wiki.debian.org/SecureApt#How_to_find_and_add_a_key > 3) Content of packages themselves may be unsecure if they trust some > third-party HTTP hosts for downloading their own > stuff. True, but not relevant to the topic of checking package integrity. Again, I think the problem is more about CONFIDENTIALITY and not integrity, even though integrity attacks are likely possible and have been demonstrated in the past. Surely they will arise again in the future in a public forum. > 4) If an user got one malicious key, game is over. True, but so it is if an > user got one malicious repo server -- > maintainer scripts from any package have root access to all of your system. I think the point is that the third-party may not necessarily be malicious, just that they are not as operationally savvy about protecting their GPG signing keys as Debian Security Team is, meaning that the NSA could attack them more easily. This could even be for an older repo that is no longer operational, but the key is still trusted in the system from a prior installation. The NSA could utilize that key to taint core Debian packages, even though the repository is no longer active. HTTPS+HPKP would make this more costly to NSA. > I'm not sure that benefits outweight the costs. HTTPS requires that I trust > the third-parties -- mirror provider and CA. HPKP was developed because you do not trust the root CA. HPKP makes forging a certificate much more costly. NSA cannot simply generate a new site certificate and sign it with their root CA, because the hash will not match. It becomes much more costly at that point to attack. > Gpgv doesn't require third parties. To me, that makes HTTPS (even with HPKP) > principally weaker than offline > medium-agnostic cryptographic content checks. Or I am wrong here, will the > suggested HTTPS+HPKP+... scheme protect me > from government players? Yes, HTTPS+HPKP is specifically designed to protect users from nation-state scale government / intelligence organization attacks. It is presumed the NSA runs their own root CA and most definitely has the ability to legally acquire a private key from a root CA operating within the USA, which are then entrusted in every browser, globally (unless you trimmed your trusted root CA lists). Sorry for the long post. I'm not as smart as you guys so it probably takes me 2x longer to explain my thoughts here... -- Regards, Kristian Erik Hermansen https://www.linkedin.com/in/kristianhermansen
