From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Leo Famulari" Subject: bug#39419: On the use of HTTPS for substitute server Date: Tue, 04 Feb 2020 18:32:29 -0500 Message-ID: <2c0b7fb7-02af-4920-845e-01ac63a8c831@www.fastmail.com> References: <87v9ombf5r.fsf@cassou.me> Mime-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:50266) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iz7gm-0005fr-6z for bug-guix@gnu.org; Tue, 04 Feb 2020 18:33:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iz7gk-0004k4-R2 for bug-guix@gnu.org; Tue, 04 Feb 2020 18:33:04 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:38960) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iz7gj-0004ev-Md for bug-guix@gnu.org; Tue, 04 Feb 2020 18:33:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iz7gj-0007Se-Jq for bug-guix@gnu.org; Tue, 04 Feb 2020 18:33:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87v9ombf5r.fsf@cassou.me> List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane-mx.org@gnu.org Sender: "bug-Guix" To: Damien Cassou , 39419@debbugs.gnu.org On Tue, Feb 4, 2020, at 09:28, Damien Cassou wrote: > In the manual, section Package Management>Substitutes, I can read: >=20 > > Substitute URLs can be either HTTP or HTTPS. HTTPS is recommended > > because communications are encrypted; conversely, using HTTP makes a= ll > > communications visible to an eavesdropper, who could use the informa= tion > > gathered to determine, for instance, whether your system has unpatch= ed > > security vulnerabilities. >=20 > A few pages later, I read: >=20 > > When using HTTPS, the server=E2=80=99s X.509 certificate is _not_ va= lidated > > (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, whi= ch > > is what we care about (whereas X.509 certificates are about > > authenticating bindings between domain names and public keys.) >=20 > Doesn't the second paragraph contradict a bit the first? It seems to m= e > that not validating a server's certificate means the client is > vulnerable to a MITM attack where the attacker would know "whether you= r > 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 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=3D ?h=3D3Dv1.0.1#n669