Re: client-side signature checking of Debian archives (Re: When should we https our mirrors?)
On Sun, Oct 23, 2016 at 10:03 AM, Eugene V. Lyubimkin <jackyf@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
Reply to: