Authenticating binary substitutes

Authenticating binary substitutes

[Ludovic Courtès]

[-- Attachment #1: Type: text/plain, Size: 1139 bytes --]

Hello,

Currently the “binary cache” substituter relies on DNS to authenticate
downloaded binaries: anything coming from, say, hydra.nixos.org is
considered authentic, because hydra.nixos.org is listed in the
‘trusted-binary-cache’ list.

This is obviously subject to person-in-the-middle attacks: one could
connect over Wifi to somebody else’s network, which happens to redirect
hydra.nixos.org to evil.example.com, and end up downloading evil binaries.

I was thinking of a simple extension to solve that:

  1a. The /nix-cache-info file would contain an (optional)
     ‘OpenPGPFingerprint’ field, to announce the fingerprint of the
     OpenPGP key used to sign Nars.

  1b. In addition to, or alternatively, a /nix-signing-key file would be
      served, containing the OpenPGP key used to sign Nars.

  2.  In addition to serving, say,
      /nar/zwpx7d0sv36fi4xpwqx2dak0axx5nji8-gmp-5.1.1, the server would
      also serve /nar/zwpx7d0sv36fi4xpwqx2dak0axx5nji8-gmp-5.1.1.sig, an
      OpenPGP binary signature of the uncompressed Nar.

WDYT?  Could this be implemented in Hydra?

Ludo’.

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Authenticating binary substitutes

[Lluís Batlle i Rossell]

On Wed, May 22, 2013 at 05:12:20PM +0200, Ludovic Courtès wrote:
> Hello,
> 
> Currently the “binary cache” substituter relies on DNS to authenticate
> downloaded binaries: anything coming from, say, hydra.nixos.org is
> considered authentic, because hydra.nixos.org is listed in the
> ‘trusted-binary-cache’ list.
> 
> This is obviously subject to person-in-the-middle attacks: one could
> connect over Wifi to somebody else’s network, which happens to redirect
> hydra.nixos.org to evil.example.com, and end up downloading evil binaries.
> 
> I was thinking of a simple extension to solve that:
> 
>   1a. The /nix-cache-info file would contain an (optional)
>      ‘OpenPGPFingerprint’ field, to announce the fingerprint of the
>      OpenPGP key used to sign Nars.
> 
>   1b. In addition to, or alternatively, a /nix-signing-key file would be
>       served, containing the OpenPGP key used to sign Nars.
> 
>   2.  In addition to serving, say,
>       /nar/zwpx7d0sv36fi4xpwqx2dak0axx5nji8-gmp-5.1.1, the server would
>       also serve /nar/zwpx7d0sv36fi4xpwqx2dak0axx5nji8-gmp-5.1.1.sig, an
>       OpenPGP binary signature of the uncompressed Nar.
> 
> WDYT?  Could this be implemented in Hydra?

I add myself to the request.

The /nix-cache-info or /nix-signing-key files should be requested
only once and stored in the local system, unless the user deletes them. If they
are fetched at every run, we are doomed again.
_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev

Re: [Nix-dev] Authenticating binary substitutes

[Ludovic Courtès]

Lluís Batlle i Rossell <viric@viric.name> skribis:

> On Wed, May 22, 2013 at 05:12:20PM +0200, Ludovic Courtès wrote:
>> Hello,
>> 
>> Currently the “binary cache” substituter relies on DNS to authenticate
>> downloaded binaries: anything coming from, say, hydra.nixos.org is
>> considered authentic, because hydra.nixos.org is listed in the
>> ‘trusted-binary-cache’ list.
>> 
>> This is obviously subject to person-in-the-middle attacks: one could
>> connect over Wifi to somebody else’s network, which happens to redirect
>> hydra.nixos.org to evil.example.com, and end up downloading evil binaries.
>> 
>> I was thinking of a simple extension to solve that:
>> 
>>   1a. The /nix-cache-info file would contain an (optional)
>>      ‘OpenPGPFingerprint’ field, to announce the fingerprint of the
>>      OpenPGP key used to sign Nars.
>> 
>>   1b. In addition to, or alternatively, a /nix-signing-key file would be
>>       served, containing the OpenPGP key used to sign Nars.
>> 
>>   2.  In addition to serving, say,
>>       /nar/zwpx7d0sv36fi4xpwqx2dak0axx5nji8-gmp-5.1.1, the server would
>>       also serve /nar/zwpx7d0sv36fi4xpwqx2dak0axx5nji8-gmp-5.1.1.sig, an
>>       OpenPGP binary signature of the uncompressed Nar.
>> 
>> WDYT?  Could this be implemented in Hydra?
>
> I add myself to the request.

Thanks.  ;-)

> The /nix-cache-info or /nix-signing-key files should be requested
> only once and stored in the local system, unless the user deletes them. If they
> are fetched at every run, we are doomed again.

Sure.  They’re only needed when you get introduced to a server anyway.

Ludo’.

Re: Authenticating binary substitutes

[Ludovic Courtès]

(Re-adding bug-guix@.)

Eelco Dolstra <eelco.dolstra@logicblox.com> skribis:

> On 22/05/13 11:12, Ludovic Courtès wrote:
>
>> Currently the “binary cache” substituter relies on DNS to authenticate
>> downloaded binaries: anything coming from, say, hydra.nixos.org is
>> considered authentic, because hydra.nixos.org is listed in the
>> ‘trusted-binary-cache’ list.
>> 
>> This is obviously subject to person-in-the-middle attacks: one could
>> connect over Wifi to somebody else’s network, which happens to redirect
>> hydra.nixos.org to evil.example.com, and end up downloading evil binaries.
>
> There is an issue about this:
>
> https://github.com/NixOS/nix/issues/75

Ah, good.

>> I was thinking of a simple extension to solve that:
>> 
>>   1a. The /nix-cache-info file would contain an (optional)
>>      ‘OpenPGPFingerprint’ field, to announce the fingerprint of the
>>      OpenPGP key used to sign Nars.
>> 
>>   1b. In addition to, or alternatively, a /nix-signing-key file would be
>>       served, containing the OpenPGP key used to sign Nars.
>> 
>>   2.  In addition to serving, say,
>>       /nar/zwpx7d0sv36fi4xpwqx2dak0axx5nji8-gmp-5.1.1, the server would
>>       also serve /nar/zwpx7d0sv36fi4xpwqx2dak0axx5nji8-gmp-5.1.1.sig, an
>>       OpenPGP binary signature of the uncompressed Nar.
>
> How about: rather than relying on nix-cache-info, nix.conf should specify a list
> of fingerprints of trusted OpenPGP signing keys.

Yes (I was focusing on the protocol, to start with.)

> Then when we fetch a .narinfo, we check whether it is signed by a
> trusted key.  This way you don't have the problem Lluís described.

I think it’s enough to sign nars.  What do you think it would add to
sign narinfos as well?

Thanks,
Ludo’.

Re: Authenticating binary substitutes

[Ludovic Courtès]

Eelco Dolstra <eelco.dolstra@logicblox.com> skribis:

> On 22/05/13 16:16, Ludovic Courtès wrote:
>
>> I think it’s enough to sign nars.  What do you think it would add to
>> sign narinfos as well?
>
> I think it's enough to sign the narinfo, since it contains the hash of the NAR
> (which Nix already verifies).

Right.

> Also, rather than having a separate .sig file, the signature could be stored in
> the narinfo file itself.  That would halve the number of HTTP requests.

Well, the .sig only needs to be downloaded when the user actually
substitutes something; this is not a situation where it would really
make a difference.

Also, how would the signature be formatted, then?

> On 22/05/13 15:19, Lluís Batlle i Rossell wrote:
>
>>> How about: rather than relying on nix-cache-info, nix.conf should specify a list
>>> of fingerprints of trusted OpenPGP signing keys.  Then when we fetch a .narinfo,
>>> we check whether it is signed by a trusted key.  This way you don't have the
>>> problem Lluís described.
>> 
>> Well, if we use gpg, gpg has its own system of trust, too. Or it's about not
>> using gpg?
>
> Now that you mention it, it would probably be better to use OpenSSL than GnuPG,
> given that we already have a (optional) dependency on OpenSSL, while GnuPG would
> be a fairly big new dependency.

I was mentioning OpenPGP (the spec), not GnuPG (an implementation).

What format and model do you have in mind?

The ideal may be SPKI/SDSI here, but OpenPGP is what people are used to,
and it’s readily available.

Ludo’.
_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev