Change Debian 8 template to use apt-transport-https by default

[isislovecruft]

In my opinion, the default Debian setting of using plaintext HTTP for package updates presents something of a security concern, since a passive adversary watching the update process gains information regarding which packages are installed and their current versions. I would strongly prefer that adversaries not know which versions of software they should be looking for bugs in in order to attack me. Debian has stalled on changing this for some time, but I see no valid reason why Qubes should persist in the same poor decisions.

Would Qubes consider having apt-transport-https installed in the Debian 8 template by default, and using an HTTPS mirror (e.g. https://mirrors.kernel.org/debian)?

[marmarek]

First of all it requires #1188 which is only present in R3.1 - so not going to happen in R3.0. But other than that, it worth consideration.

Possible downsides:

• not able make use of (transparent) caching

Alternatives:

• download updates over Tor (which is already an option in R3.1), related to #1159

/cc @adrelanos

[marmarek]

First of all it requires #1188 which is only present in R3.1 - so not going to happen in R3.0. But other than that, it worth consideration.

Possible downsides:

• not able make use of (transparent) caching

Alternatives:

• download updates over Tor (which is already an option in R3.1), related to #1159

/cc @adrelanos

[adrelanos]

Created marmarek/qubes-builder-debian#23 to install apt-transport-https by default. Not a big deal. Small change. Small package.

If however it makes sense to update over https depends on how much one trusts the broken SSL CA system in relation to their adversaries.

[adrelanos]

Created marmarek/qubes-builder-debian#23 to install apt-transport-https by default. Not a big deal. Small change. Small package.

If however it makes sense to update over https depends on how much one trusts the broken SSL CA system in relation to their adversaries.

[mig5]

Just implementing this myself now on templates carried over from 3.0 to 3.1. I think there isn't any alternative mirror for the security updates available at http://security.debian.org. And there isn't any HTTPS for security.debian.org (disappointed). So correct me if I'm wrong but this will always be only a partial fix that Qubes project can't solve :(

[mig5]

Just implementing this myself now on templates carried over from 3.0 to 3.1. I think there isn't any alternative mirror for the security updates available at http://security.debian.org. And there isn't any HTTPS for security.debian.org (disappointed). So correct me if I'm wrong but this will always be only a partial fix that Qubes project can't solve :(

[unman]

It's trivially easy to assess which packages are being installed under TLS, so privacy is illusory.

As @mig says, Debian security updates are not available by HTTPS, so method cant be absolute default.
@adrelanos has already added apt-transport-https method.
Is there any purpose in shipping templates with HTTPS across all sources except security.debian.org ?

[unman]

It's trivially easy to assess which packages are being installed under TLS, so privacy is illusory.

As @mig says, Debian security updates are not available by HTTPS, so method cant be absolute default.
@adrelanos has already added apt-transport-https method.
Is there any purpose in shipping templates with HTTPS across all sources except security.debian.org ?

[rustybird]

@marmarek:

Possible downsides:

• not able make use of (transparent) caching

Indeed.

@isislovecruft:

You can get HTTPS+caching for Debian packages if you use qubes-updates-cache and remove the comment character from line 9 of /etc/qubes-updates-cache/urls.conf (and from line 4 for Fedora packages).

[rustybird]

@marmarek:

Possible downsides:

• not able make use of (transparent) caching

Indeed.

@isislovecruft:

You can get HTTPS+caching for Debian packages if you use qubes-updates-cache and remove the comment character from line 9 of /etc/qubes-updates-cache/urls.conf (and from line 4 for Fedora packages).

[unman]

@marmarek @isislovecruft
can we move on this?

1. @adrelanos has added support for apt-transport-https, so users can easily configure if they wish;
2. Debian security isn't available at all via https
3. It's straightforward to identify package updates over TLS
4. The fedora templates use http and https

I would leave as present and leave it to users to configure, but if it's decided to move to default https it's a trivial change.

[unman]

@marmarek @isislovecruft
can we move on this?

1. @adrelanos has added support for apt-transport-https, so users can easily configure if they wish;
2. Debian security isn't available at all via https
3. It's straightforward to identify package updates over TLS
4. The fedora templates use http and https

I would leave as present and leave it to users to configure, but if it's decided to move to default https it's a trivial change.

[marmarek]

I'd also leave as it is. Much easier (in terms of configuration) solution is to connect template through Whonix Gateway - which gives much more than https (you can hide that you download updates at all, not only what updates). It is even possible to select such option during installation.

[marmarek]

I'd also leave as it is. Much easier (in terms of configuration) solution is to connect template through Whonix Gateway - which gives much more than https (you can hide that you download updates at all, not only what updates). It is even possible to select such option during installation.

[unman]

@andrewdavidwong Please close "Won't Fix"

[unman]

@andrewdavidwong Please close "Won't Fix"