bug#39419: On the use of HTTPS for substitute server

bug#39419: On the use of HTTPS for substitute server

[Damien Cassou]

In the manual, section Package Management>Substitutes, I can read:

> Substitute URLs can be either HTTP or HTTPS. HTTPS is recommended
> because communications are encrypted; conversely, using HTTP makes all
> communications visible to an eavesdropper, who could use the information
> gathered to determine, for instance, whether your system has unpatched
> security vulnerabilities.

A few pages later, I read:

> When using HTTPS, the server’s X.509 certificate is _not_ validated
> (in other words, the server is not authenticated), contrary to what
> HTTPS clients such as Web browsers usually do.  This is because Guix
> authenticates substitute information itself, as explained above, which
> is what we care about (whereas X.509 certificates are about
> authenticating bindings between domain names and public keys.)

Doesn't the second paragraph contradict a bit the first? It seems to me
that not validating a server's certificate means the client is
vulnerable to a MITM attack where the attacker would know "whether your
system has unpatched security vulnerabilities".

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

bug#39419: On the use of HTTPS for substitute server

[Leo Famulari]

On Tue, Feb 4, 2020, at 09:28, Damien Cassou wrote:
> In the manual, section Package Management>Substitutes, I can read:
> 
> > Substitute URLs can be either HTTP or HTTPS. HTTPS is recommended
> > because communications are encrypted; conversely, using HTTP makes all
> > communications visible to an eavesdropper, who could use the information
> > gathered to determine, for instance, whether your system has unpatched
> > security vulnerabilities.
> 
> A few pages later, I read:
> 
> > When using HTTPS, the server’s X.509 certificate is _not_ validated
> > (in other words, the server is not authenticated), contrary to what
> > HTTPS clients such as Web browsers usually do.  This is because Guix
> > authenticates substitute information itself, as explained above, which
> > is what we care about (whereas X.509 certificates are about
> > authenticating bindings between domain names and public keys.)
> 
> Doesn't the second paragraph contradict a bit the first? It seems to me
> that not validating a server's certificate means the client is
> vulnerable to a MITM attack where the attacker would know "whether your
> system has unpatched security vulnerabilities".

When substituting over HTTPS, the communication session with the remote
server is encrypted using TLS, as expected. It is guarded against
passive eavesdropping. However, the certificate itself is not validated
against the X.509 PKI (Mozilla's).

So, someone who could MITM as <https://ci.guix.gnu.org> could use their
own X.509 certificate and pretend to be that server.

With this capability, they could send you substitutes that your Guix
would then authenticate as having been signed by the official Guix
substitute signing key. Guix would also check that it was the substitute
it had asked for. So, unless we have missed something, the worst case is
you get the right data from the wrong server.

Guix's security model already supports mirroring of substitutes by
arbitrary remote servers. That is, the security model is about signing
substitutes, not authenticating remote servers. So, I think that it's
not very important to verify TLS certs here, and not needing a working
certificate store for substitutes improves reliability.

The relevant code for the latest Guix release is here:

https://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/substitute.scm=
?h=3Dv1.0.1#n669

bug#39419: On the use of HTTPS for substitute server

[Damien Cassou]

"Leo Famulari" <leo@famulari.name> writes:
> So, someone who could MITM as <https://ci.guix.gnu.org> could use their
> own X.509 certificate and pretend to be that server.

IIUC, you agree with me that an attacker can't change the content of
packages but can inspect what a user installs. This seems to contradict
this paragraph:

> HTTPS is recommended because communications are encrypted; conversely,
> using HTTP makes all communications visible to an eavesdropper, who
> could use the information gathered to determine, for instance, whether
> your system has unpatched security vulnerabilities.


If you believe the text is good as it is, please just ignore me and
close the ticket.

Thank you so much for Guix.

-- 
Damien Cassou

"Success is the ability to go from one failure to another without
losing enthusiasm." --Winston Churchill

bug#39419: On the use of HTTPS for substitute server

[Leo Famulari]

On Wed, Feb 05, 2020 at 11:34:49AM +0100, Damien Cassou wrote:
> "Leo Famulari" <leo@famulari.name> writes:
> > So, someone who could MITM as <https://ci.guix.gnu.org> could use their
> > own X.509 certificate and pretend to be that server.
> 
> IIUC, you agree with me that an attacker can't change the content of
> packages but can inspect what a user installs. This seems to contradict
> this paragraph:
> 
> > HTTPS is recommended because communications are encrypted; conversely,
> > using HTTP makes all communications visible to an eavesdropper, who
> > could use the information gathered to determine, for instance, whether
> > your system has unpatched security vulnerabilities.

It is somewhat contradictory.

The server that sends your substitutes knows what substitutes you
request, by definition.

How important is that information, and what tradeoffs are we willing to
make to protect it? Guix protects this information from passive
eavesdroppers but not an active MITM.

The real important thing is, what substitutes are you requesting? This
is based on your Guix code, and we do authenticate the server you
request that from (`guix pull`). The next step is to start using
code-signing there. This is a work in progress.

> If you believe the text is good as it is, please just ignore me and
> close the ticket.

Okay, closed. Please let us know if you think the text can be improved.