GNU bug report logs - #29046
[PATCH] gnu: linux-libre: Update to 4.13.10 and change URL to HTTPS.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29046 in the body.
You can then email your comments to 29046 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Rutger Helling <rhelling <at> mykolab.com>
To: guix-patches <at> gnu.org
Subject: [PATCH] gnu: linux-libre: Update to 4.13.10 and change URL to HTTPS.
Date: Sat, 28 Oct 2017 23:15:16 +0200

[Message part 1 (text/plain, inline)]

Hey Guix, 

here's a patch to update linux-libre and change the URL to HTTPS.

[Message part 2 (text/html, inline)]

[0001-gnu-linux-libre-Update-to-4.13.10-and-change-URL-to-.patch (text/x-diff, attachment)]

Message #8 received at 29046 <at> debbugs.gnu.org (full text, mbox):

From: Rutger Helling <rhelling <at> mykolab.com>
To: 29046 <at> debbugs.gnu.org
Subject: [PATCH] gnu: linux-libre: Change URL to HTTPS.
Date: Mon, 30 Oct 2017 08:06:39 +0100

[Message part 1 (text/plain, inline)]

I noticed linux-libre had already been updated, so this new patch only
changes the URL to HTTPS.

[Message part 2 (text/html, inline)]

[0001-gnu-linux-libre-Change-URL-to-HTTPS.patch (text/x-diff, attachment)]

Message #11 received at 29046 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Rutger Helling <rhelling <at> mykolab.com>
Cc: 29046 <at> debbugs.gnu.org, "Mark H. Weaver" <mhw <at> netris.org>
Subject: Re: [bug#29046] [PATCH] gnu: linux-libre: Change URL to HTTPS.
Date: Mon, 30 Oct 2017 10:44:08 -0400

[Message part 1 (text/plain, inline)]

On Mon, Oct 30, 2017 at 08:06:39AM +0100, Rutger Helling wrote:
> I noticed linux-libre had already been updated, so this new patch only
> changes the URL to HTTPS.

> From b68a2c630258324628a7ef34005ff1d790a3a139 Mon Sep 17 00:00:00 2001
> From: Rutger Helling <rhelling <at> mykolab.com>
> Date: Mon, 30 Oct 2017 08:02:10 +0100
> Subject: [PATCH] gnu: linux-libre: Change URL to HTTPS.
> 
> * gnu/packages/linux.scm (linux-libre): Change URL to HTTPS.

Hi! Thanks for paying attention to the linux-libre packages.

I'm copying Mark on this email, since he typically handles the
linux-libre packages. Mark, what do you think of this change?

[signature.asc (application/pgp-signature, inline)]

Message #14 received at 29046 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Leo Famulari <leo <at> famulari.name>
Cc: 29046 <at> debbugs.gnu.org, Rutger Helling <rhelling <at> mykolab.com>
Subject: Re: [bug#29046] [PATCH] gnu: linux-libre: Change URL to HTTPS.
Date: Mon, 30 Oct 2017 15:14:10 -0400

Hi Leo,

Leo Famulari <leo <at> famulari.name> writes:

> On Mon, Oct 30, 2017 at 08:06:39AM +0100, Rutger Helling wrote:
>> I noticed linux-libre had already been updated, so this new patch only
>> changes the URL to HTTPS.
>
>> From b68a2c630258324628a7ef34005ff1d790a3a139 Mon Sep 17 00:00:00 2001
>> From: Rutger Helling <rhelling <at> mykolab.com>
>> Date: Mon, 30 Oct 2017 08:02:10 +0100
>> Subject: [PATCH] gnu: linux-libre: Change URL to HTTPS.
>> 
>> * gnu/packages/linux.scm (linux-libre): Change URL to HTTPS.
>
> Hi! Thanks for paying attention to the linux-libre packages.
>
> I'm copying Mark on this email, since he typically handles the
> linux-libre packages. Mark, what do you think of this change?

Thanks for bringing this to my attention.

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?

      Mark

Message #17 received at 29046 <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 29046 <at> debbugs.gnu.org, Rutger Helling <rhelling <at> mykolab.com>
Subject: Re: [bug#29046] [PATCH] gnu: linux-libre: Change URL to HTTPS.
Date: Mon, 30 Oct 2017 22:22:14 -0400

[Message part 1 (text/plain, inline)]

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?

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 29046 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Leo Famulari <leo <at> famulari.name>
Cc: 29046 <at> debbugs.gnu.org, Mark H Weaver <mhw <at> netris.org>,
 Rutger Helling <rhelling <at> mykolab.com>
Subject: Re: [bug#29046] [PATCH] gnu: linux-libre: Change URL to HTTPS.
Date: Tue, 07 Nov 2017 17:26:20 +0100

Hi,

Replying to an old message…

Leo Famulari <leo <at> famulari.name> 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’.

Message #23 received at 29046 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: ludo <at> gnu.org (Ludovic Courtès)
Cc: 29046 <at> debbugs.gnu.org, Rutger Helling <rhelling <at> mykolab.com>,
 Leo Famulari <leo <at> famulari.name>
Subject: Re: [bug#29046] [PATCH] gnu: linux-libre: Change URL to HTTPS.
Date: Tue, 07 Nov 2017 14:05:24 -0500

Hi,

ludo <at> gnu.org (Ludovic Courtès) writes:

> Leo Famulari <leo <at> famulari.name> 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

Is an active attack needed to determine which file we are downloading
from linux-libre.fsfla.org?  I think not.  The IP address of that host
reverse resolves to "linux-libre.fsfla.org", which makes it obvious.
The title of the paper Ludovic cited above makes the point:

  I Know Why You Went to the Clinic

or in this case:

  I know why you downloaded 97 megabytes from linux-libre.fsfla.org.

Unless I'm mistaken, using TLS does *not* foil passive surveillance for
source downloads in the overwhelming majority of cases, and especially
not in this case.  Even at web sites that serve a larger variety of
software, determining what was downloaded by the amount of data
transferred does not require an active attack.

Anyway, having said this, if using HTTPS for linux-libre downloads makes
you sleep better at night, I'm okay with it.

     Regards,
       Mark

Message #26 received at 29046 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Mark H Weaver <mhw <at> netris.org>
Cc: 29046 <at> debbugs.gnu.org, Rutger Helling <rhelling <at> mykolab.com>,
 Leo Famulari <leo <at> famulari.name>
Subject: Re: [bug#29046] [PATCH] gnu: linux-libre: Change URL to HTTPS.
Date: Tue, 07 Nov 2017 22:12:31 +0100

Mark H Weaver <mhw <at> netris.org> skribis:

> Is an active attack needed to determine which file we are downloading
> from linux-libre.fsfla.org?  I think not.  The IP address of that host
> reverse resolves to "linux-libre.fsfla.org", which makes it obvious.
> The title of the paper Ludovic cited above makes the point:
>
>   I Know Why You Went to the Clinic
>
> or in this case:
>
>   I know why you downloaded 97 megabytes from linux-libre.fsfla.org.
>
> Unless I'm mistaken, using TLS does *not* foil passive surveillance for
> source downloads in the overwhelming majority of cases, and especially
> not in this case.  Even at web sites that serve a larger variety of
> software, determining what was downloaded by the amount of data
> transferred does not require an active attack.

You’re right, though it’s already more work for github.com (11% of our
packages) or PyPI (17% of our packages).

This discussion is also interesting in the context of
<https://bugs.gnu.org/28659>, where one of the options discussed would
be to favor content-addressable mirrors over upstream sites.

Ludo’.

Message #31 received at 29046-done <at> debbugs.gnu.org (full text, mbox):

From: Leo Famulari <leo <at> famulari.name>
To: Mark H Weaver <mhw <at> netris.org>
Cc: 29046-done <at> debbugs.gnu.org,
 Ludovic Courtès <ludo <at> gnu.org>,
 Rutger Helling <rhelling <at> mykolab.com>
Subject: Re: [bug#29046] [PATCH] gnu: linux-libre: Change URL to HTTPS.
Date: Sun, 12 Nov 2017 15:48:04 -0500

[Message part 1 (text/plain, inline)]

On Tue, Nov 07, 2017 at 02:05:24PM -0500, Mark H Weaver wrote:
> Is an active attack needed to determine which file we are downloading
> from linux-libre.fsfla.org?  I think not.  The IP address of that host
> reverse resolves to "linux-libre.fsfla.org", which makes it obvious.
> The title of the paper Ludovic cited above makes the point:

I should clarify that by "active attacker" I mean someone who is doing
anything beyond simply recording the traffic. So, if they are making
lists of file sizes of different kernel tarballs, or keeping a database
of which sites you visited, keyed by your IP / identity, that's
"active".

> Anyway, having said this, if using HTTPS for linux-libre downloads makes
> you sleep better at night, I'm okay with it.

It doesn't affect my rest, but I assume you are speaking metaphorically.
So, I pushed the change as 8420c7a3565b6a984cdd95336f66d555edc87d90.

Thanks Rutger!

[signature.asc (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.