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

[Ludovic Courtès]

Hi,

Replying to an old message…

Leo Famulari <address@hidden> skribis:

> 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 very much sympathize with everything you wrote.  Regarding
eavesdropping (which to me is the main reason to change to HTTPS in this
context), the “bicycle attack” kinda confirms that HTTPS is not so good
at protecting from eavesdropping: <http://arxiv.org/pdf/1403.0297.pdf>.

However, it remains a relatively elaborate attack: I can trivially see
what you are getting over HTTP, and I would have to target you and be
fairly determined to analyze your HTTPS traffic.  So overall, I still
think that HTTPS improves privacy, even if we must be aware of its
limitation.

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

+1

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

Right.

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

Yeah.

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

I’m in favor of it as well.

Thanks,
Ludo’.