[Nix-dev] [yui at cock.li: Re: Malicious installation methods]
Yui Hirasawa
yui at cock.li
Fri Jun 17 17:17:56 CEST 2016
> Assuming a MITM it's already game over here, the MITM doesn't even have to
> control one of the CAs.
No. If you are verifying the GPG signature it is not game over. It
doesn't matter how you retrieve the signature and the signed file if you
verify them, this is assuming that the crypto primitives aren't broken.
> There is also an alternative verification method: `gpg --keyserver
> keys.gnupg.net --recv-keys 3D9AEBB5`. Assuming a MITM, keys.gnupg.net is
> accessed in clear. And generating a GPG key with the same key ID is
> trivial. So game over again.
This is true. Retrieving the key is not a trivial problem. This is why
projects should start printing their fingerprint on all promotional
material and on every website and on every talk they give. This way it
is easier to verify that you have the right key. For example some people
who give talks at defcon or CCC have their fingerprints on the first or
last or in some cases every slide.
> At that point there are still two pages of instructions to follow to get
> guix installed, with no additional security benefits.
There are security benefits in the Guix install method, they just aren't
as big as they could be. And the lenght of the Guix installation doesn't
really matter since most of it doesn't have to do with retrieving the
installer.
> I don't mean to say that GPG is a bad idea. It just that using SSL is a
> better idea unless we nail the GPG bit. Not everyone is getting
> state-sponsored attacks.
SSL is deprecated. The current standard that's in use is TLS. Attacks on
our CA system doesn't require a state-sponsored attack, it just requires
enough money to convenience a CA to give you a cert or that you yourself
have a trusted intermediate and as someone in a previous message
mentioned there are hundreds if not thousands of such organizations.
Even sub-optimal usage of GPG is still far far superior to just trusting
TLS.
More information about the nix-dev
mailing list