From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60527) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e9MCq-00017s-5T for guix-patches@gnu.org; Mon, 30 Oct 2017 22:23:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e9MCl-0006QC-7s for guix-patches@gnu.org; Mon, 30 Oct 2017 22:23:08 -0400 Received: from debbugs.gnu.org ([208.118.235.43]:34332) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e9MCk-0006PL-TM for guix-patches@gnu.org; Mon, 30 Oct 2017 22:23:03 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1e9MCk-00036n-KI for guix-patches@gnu.org; Mon, 30 Oct 2017 22:23:02 -0400 Subject: [bug#29046] [PATCH] gnu: linux-libre: Change URL to HTTPS. Resent-Message-ID: Date: Mon, 30 Oct 2017 22:22:14 -0400 From: Leo Famulari Message-ID: <20171031022214.GA21447@jasmine.lan> References: <70ee5da890c2fe609d54af4a3e1f18df@mykolab.com> <30a6703bf921961424f93af098f2ec8f@mykolab.com> <20171030144408.GB27298@jasmine.lan> <87po94cut9.fsf@netris.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="envbJBWh7q8WU6mo" Content-Disposition: inline In-Reply-To: <87po94cut9.fsf@netris.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-patches-bounces+kyle=kyleam.com@gnu.org Sender: "Guix-patches" To: Mark H Weaver Cc: 29046@debbugs.gnu.org, Rutger Helling --envbJBWh7q8WU6mo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 30, 2017 at 03:14:10PM -0400, Mark H Weaver wrote: > I'm not strongly opposed to it, but in general, I'm not sure I > understand the rationale for changing source URLs to use HTTPS. We > already verify the authenticity of the downloaded file by SHA256 hash, > and verify the GPG signature when updating to a new version. Both of > these are far stronger than HTTPS, which in practice can be subverted by > compromising *any* certificate authority listed in our trust database > (in Mozilla NSS). > > HTTPS also fails to hide from an evesdropper which file was downloaded, > because in practice that can be determined by the amount of data > transferred. >=20 > So, unless I'm mistaken, HTTPS doesn't provide any benefit to us here. > On the other hand, using HTTPS entails using more complex code to > download the files, which exposes a much larger attack surface that > might be exploited to compromise our systems. Many security flaws have > been uncovered in TLS libraries over the years. Using HTTPS also adds > more load on the server. >=20 > In summary, I'm mildly opposed to this change, but if I've made a > mistake in my reasoning here, or if other people feel strongly, I'm okay > either way. >=20 > What do you think? I think I'm more bullish on the TLS X.509 PKI than you but I basically agree with your points. We wouldn't gain anything with regards to the integrity of the downloaded files and the HTTPS client software is probably more complex than for unauthenticated HTTP. It's true that, in this case, an active attacker could probably learn which file you are downloading. But using TLS would foil passive surveillance, which is probably widespread. If I understand correctly we don't actually verify certificates when downloading sources while building because we verify the integrity of the files via the SHA256 hash, out of band. If we did verify the certificates, I would argue that using TLS is an improvement here because it could reduce the feasibility of exploits of the download client and SHA256 verifier by MITM attackers. Examples of this type of attack would be (hypothetical) exploits of CVE-2017-13089 and CVE-2017-13090, recently fixed in wget. IIUC, those bugs in the wget client could be exploited by any MITM attacker; using TLS to ensure the client is talking to the right server would help. As it is, an attacker with knowledge of how Guix works could easily circumvent TLS in this sort of scenario, since we don't verify the certificates. Besides, as you mentioned previously, the TLS client brings its own bugs. Because I think that using HTTPS here reduces the effectiveness of totally passive surveillance, I'm in favor of the change. What do you think? And anyone else? --envbJBWh7q8WU6mo Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEsFFZSPHn08G5gDigJkb6MLrKfwgFAln33lMACgkQJkb6MLrK fwiniQ/9EId0LhxupCaqSpjWLwTGA0D+kDkbmB5ft0/NDauMj6XfEJcmTA6ZDm3X p2Gup3s3D6i9/qhMHBa4Z16hFvEx7HdK6h3AoRxsxE6L3LnVa49EZrohMZJLsLzi w+BRV6zRYspWMNqfQeKeMqzlwuWrf128MUeGkKxIJ08tMh0x417fe4HGQYt+48al LLCvr73S7U/yU2OirXYWl7fLJHNBW7znXQtx0JSVzdMwrlXnVtSEc/AkbOfI7jNf KB5fctVatfKgchY8FVEV/Iiqu1x6msuuBEp68iiS1x961V7FO7WN9YNKNyTPEYzN xC16qzNT9uepgJc5x9aTahicLSdzSO+1yn4lpcsSYquCWxasI74xGm1OzLWhG4+F Ngw8fI20M7FyQbD9Xj6CRfZ9fKuGMcIHn82svJBcBwJh0PckW9m24JYhScYM/7JL HkOsuGORwgfxUnvwlgsuwQRqbFpDf6Adk/VpTgG7Veelxqkl2omxS0zKBqpLPlZW VV5m1RvH8njmltN6nZeAB0Mt2L4MKZWepFKcRStZt3Ngzh8ToeLyI/KiF7hNTEXX QNvxIziowGf9zJxV0tnbS+pBdWDh7aI5BxHfYNWwnChkeXhYiYpvGAWRWgn1a3es 6hOoqI6TeyGpv7utxmsTDpzbv1cBp4yesDjLyMMfoR3af2cqzWU= =3UA6 -----END PGP SIGNATURE----- --envbJBWh7q8WU6mo--