[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#29046] [PATCH] gnu: linux-libre: Change URL to HTTPS.

From: Leo Famulari
Subject: [bug#29046] [PATCH] gnu: linux-libre: Change URL to HTTPS.
Date: Mon, 30 Oct 2017 22:22:14 -0400
User-agent: Mutt/1.9.1 (2017-09-22)

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

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]