Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

[Yui Hirasawa]

>>> 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.
>
> Unless I misunderstood something all you are verifying is that the
> attacker's GPG signature matches the attacker's archive. This just
> gives you a false sense of security.

It doesn't really matter if the wrong signature and archive match since
you don't even have the attackers key.

>>> 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.
>>
>
> I agree. For GPG to be implemented properly, the key must be
> distributed separately from the content. The goal is to make the
> attack more expensive by forcing the attacker to compromise multiple
> communication channels. And the key fingerprint must be in the long
> form to mitigate potential collision attacks.

7B29 6212 4A73 E1E9 15E8  A7D4 7F96 C964 9CBC BF51 <- This is a fingerprint

9CBCBF51 <- This is just a short id
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

[zimbatm]

On Fri, 17 Jun 2016 at 16:35 Jookia <166...@gmail.com> wrote:

> On Fri, Jun 17, 2016 at 03:01:00PM +, zimbatm wrote:
> > 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.
>
> TLS and GPG aren't mutually exclusive, you can use both. It's also worth
> noting
> that states aren't the only people attacking TLS: Tor exit nodes like to
> do it
> too. It does trouble me that there's no way to really verify that I have a
> copy
> of Nix that the maintainers have. Right now I check out with an unverified
> Git
> repository which isn't much better either. It'd be nice to at least try to
> have
> verification.
>

I suppose we could distribute the installation script as part of a hydra
build. That way it would be signed like the rest of the packages. It does
suppose that the build hosts aren't compromised though.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

[zimbatm]

On Fri, 17 Jun 2016 at 16:18 Yui Hirasawa  wrote:

> > 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.
>

Unless I misunderstood something all you are verifying is that the attacker's
GPG signature matches the attacker's archive. This just gives you a false
sense of security.

> 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.
>

I agree. For GPG to be implemented properly, the key must be distributed
separately from the content. The goal is to make the attack more expensive
by forcing the attacker to compromise multiple communication channels. And
the key fingerprint must be in the long form to mitigate potential
collision attacks.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

[Jookia]

On Fri, Jun 17, 2016 at 03:01:00PM +, zimbatm wrote:
> 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.

TLS and GPG aren't mutually exclusive, you can use both. It's also worth noting
that states aren't the only people attacking TLS: Tor exit nodes like to do it
too. It does trouble me that there's no way to really verify that I have a copy
of Nix that the maintainers have. Right now I check out with an unverified Git
repository which isn't much better either. It'd be nice to at least try to have
verification.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

[Yui Hirasawa]

> 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.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

[Adrien Devresse]

> I agree with this. A key that is trusted itself (rather then trusting a
> domain name) would be a very large security increase.

I agree too.

And this more or less the way taken by RPM / DPKG that ship their
trusted key on the client side when you install a new repository instead
of relying on any CA or PGP keyserver.


Adev



Le 17/06/2016 16:35, Kevin Cox a écrit :
> On 17/06/16 10:33, Yui Hirasawa wrote:
>>> Signing the installer script would provide only a minor increase in
>>> security (in that it would require the signing key to be compromised,
>>> rather than the nixos.org certificate). I don't object to doing that
>>> though.
>> That is quite a major increase in security actually. Compromising a key
>> that can be kept offline most of the time is a lot harder than obtaining
>> a signed certificate for the nixos.org domain. You do not have to have
>> the original nixos.org certificate to perform man-in-the-middle attack.
>>
> I agree with this. A key that is trusted itself (rather then trusting a
> domain name) would be a very large security increase.
>
>
>
>
> ___
> nix-dev mailing list
> nix-dev@lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

[Kevin Cox]

On 17/06/16 10:33, Yui Hirasawa wrote:
>
>> Signing the installer script would provide only a minor increase in
>> security (in that it would require the signing key to be compromised,
>> rather than the nixos.org certificate). I don't object to doing that
>> though.
> 
> That is quite a major increase in security actually. Compromising a key
> that can be kept offline most of the time is a lot harder than obtaining
> a signed certificate for the nixos.org domain. You do not have to have
> the original nixos.org certificate to perform man-in-the-middle attack.
>

I agree with this. A key that is trusted itself (rather then trusting a
domain name) would be a very large security increase.




signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

[Kevin Cox]

On 17/06/16 10:26, Eelco Dolstra wrote:
> 
> Cargo cult security is not a priority. I wouldn't worry about "curl | bash" 
> but
> not the giant binary tarball downloaded and executed by that script (or
> equivalently, installing a binary RPM or Deb package). Signing the installer
> script would provide only a minor increase in security (in that it would 
> require
> the signing key to be compromised, rather than the nixos.org certificate). I
> don't object to doing that though.
> 

I generally agree wit this. I think moving the whole system to offline
signing would be nice but I don't think it's very urgent.

Another advantage of moving away from the CA system is that the CA
system can be bypassed if any of hundreds (thousands?) of CAs are
compromised, or if the Nix servers are compromised. Where as if it is an
"offline" key (even if it's an online PGP key it would be better). There
is a single, more difficult attack surface.



signature.asc
Description: OpenPGP digital signature
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

[Yui Hirasawa]

>> HTTPS is not a verified channel. Our current CA system is really
>> fragile
>
> It is, but it works a lot better than the PGP web of trust in that it
> doesn't require people to get together to engage in quaint key signing
> rituals.

PGP has a web of trust but in our CA anyone with intermediate that is
trusted can impersonate anyone they want and no one would notice unless
they manually go and check who has signed the server cert. Unfortunately
we don't have anything that would work better than key signing rituals
and the CA system we have is objectively worse in every way except in
that the keys are already trusted and the user doesn't have to even know
they are there, and even this can be seen as a negative thing for
security.

> Signing the installer script would provide only a minor increase in
> security (in that it would require the signing key to be compromised,
> rather than the nixos.org certificate). I don't object to doing that
> though.

That is quite a major increase in security actually. Compromising a key
that can be kept offline most of the time is a lot harder than obtaining
a signed certificate for the nixos.org domain. You do not have to have
the original nixos.org certificate to perform man-in-the-middle attack.
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] [y...@cock.li: Re: Malicious installation methods]

[Eelco Dolstra]

Hi,

On 06/17/2016 03:56 PM, Yui Hirasawa wrote:

> HTTPS is not a verified channel. Our current CA system is really fragile

It is, but it works a lot better than the PGP web of trust in that it doesn't
require people to get together to engage in quaint key signing rituals.

> Here is a quote from the #nix channel: 
> 
>> kmicu: Tsutsukakushi: I told ya so… security is not a priority here.

Cargo cult security is not a priority. I wouldn't worry about "curl | bash" but
not the giant binary tarball downloaded and executed by that script (or
equivalently, installing a binary RPM or Deb package). Signing the installer
script would provide only a minor increase in security (in that it would require
the signing key to be compromised, rather than the nixos.org certificate). I
don't object to doing that though.

-- 
Eelco Dolstra | LogicBlox, Inc. | http://nixos.org/~eelco/
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

[Nix-dev] [y...@cock.li: Re: Malicious installation methods]

[Yui Hirasawa]

>> Retrieving code straight from the internet and blindly executing is
>> never a good thing and you don't give any sort of recommendation for
>> the user to inspect the script before running it. This completely
>> defeats the point of having reproducible builds when your system can
>> be completely infected when you install the package manager. This
>> also means that anything installed through the package manager is
>> potentially malicious as well.
>>
>>> $ curl https://nixos.org/nix/install | sh
>>

> and the distribution method is over a verified channel

HTTPS is not a verified channel. Our current CA system is really fragile
and there is a large number of advesaries who could easily acquire a
fake certificate for nixos.org. This method is only verified if you
actually check that the certificate that was used for the TLS
connection is the correct one for nixos.org, and currently you have to
do that manually. Verifying the connection to nixos.org is more work
than verifying a GPG signature.

> One improvement would be to sign the actual script with an offline key
> but while that would be safer the current method is perfectly fine.

The current method isn't fine at all.

Here is a quote from the #nix channel: 

> kmicu: Tsutsukakushi: I told ya so… security is not a priority here.
> Fell free to try to improve security in Nix world, but you are better
> off with Guix. They even don’t trust compilers w/o bootstrapping from
> the source option :)
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev