all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Leo Famulari <leo@famulari.name>
To: Mark H Weaver <mhw@netris.org>
Cc: 29046@debbugs.gnu.org, Rutger Helling <rhelling@mykolab.com>
Subject: [bug#29046] [PATCH] gnu: linux-libre: Change URL to HTTPS.
Date: Mon, 30 Oct 2017 22:22:14 -0400	[thread overview]
Message-ID: <20171031022214.GA21447@jasmine.lan> (raw)
In-Reply-To: <87po94cut9.fsf@netris.org>

[-- Attachment #1: Type: text/plain, Size: 2790 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2017-10-31  2:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-28 21:15 [bug#29046] [PATCH] gnu: linux-libre: Update to 4.13.10 and change URL to HTTPS Rutger Helling
2017-10-30  7:06 ` [bug#29046] [PATCH] gnu: linux-libre: Change " Rutger Helling
2017-10-30 14:44   ` Leo Famulari
2017-10-30 19:14     ` Mark H Weaver
2017-10-31  2:22       ` Leo Famulari [this message]
2017-11-07 16:26         ` Ludovic Courtès
2017-11-07 19:05           ` Mark H Weaver
2017-11-07 21:12             ` Ludovic Courtès
2017-11-12 20:48             ` bug#29046: " Leo Famulari

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171031022214.GA21447@jasmine.lan \
    --to=leo@famulari.name \
    --cc=29046@debbugs.gnu.org \
    --cc=mhw@netris.org \
    --cc=rhelling@mykolab.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.