apt-transport-https and Qubes proxy

[Jeremy Rand]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I'm running Qubes-Whonix, and I noticed that when I tried to install a
package into the template that used apt-transport-https, I
consistently got a 403 error when running apt-get update. (The
package repo I was using was the Tox nightly build repo.) After much
confusion, I noticed that appending the following line to
/etc/apt/apt.conf.d/01qubes-proxy fixed the issue and allowed the
package to be installed:

Acquire::https::Proxy "DIRECT";

Is it intended behavior that apt-transport-https will fail in
templates by default? If so, no workaround appears to be documented.
Is my workaround the correct one?

Thanks,
- -Jeremy Rand
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVqHdoAAoJEAHN/EbZ1y06XbwP/3OFsCrJjTApcsajkV+ov2K/
TPDqggf0Bf5/77/gLxDKGul2t6JwIVFKIrL8GXXChZGxEmJTdrKQNRUu2rZGqS3Q
pcQ+kOEjmi+EXoluRZePlX+KigjZMwgDtb5anZiCj4wBQTkAWPhsxqIu0PphTtRK
yjWwEE8tPBgRH5yOMXrL221dzhtICxoJsiVbjktJf2FsaHKb+4dlN/ovDCB32Wdz
WaCE64GUhaVxuQy4WYYrYqZEM5WTOvOCH/c6gL7Lhtzoheeyuh866QEQ9UH1PD7j
B4ixrMx3jnEmeXX503i9d7nD3FvlSyVfEXmrDjUa5bXKkcR3TavnFiBHmvmAs7Z2
AeF+3IJ6JTgZgAQHm+IpXuhEOZawTu8I79sC5PPgaHv+WIRdMGRm3LLSyOMWJPLm
90PfYU4dwMZgOJCHCt9NemQAjQR39+UGEdKe8x9MyFhFHBmDsDU8UWJ020dunP1S
RStw7zvIzT0jtIHjrNFlf2L8XsTVpKsBtAKc0rG7B88ojHEh2j3i25s95lkX5BlV
jcV742dy8m8tT7ev2zBFUTWtzln6KvmJD7np6MBcuPSAYEkQs89E4Y0Hk3NIZJ5d
I5cmqALjcHqiswwXWJtVyo6SCqh1bXO++cO3Rtjc2DMppv6Vi4MtFHeXCWbRpq2j
/biVOD5GutVE6rqIsrtO
=aomd
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Thu, Jul 16, 2015 at 10:33:20PM -0500, Jeremy Rand wrote:
> I'm running Qubes-Whonix, and I noticed that when I tried to install a
> package into the template that used apt-transport-https, I
> consistently got a 403 error when running apt-get update. (The
> package repo I was using was the Tox nightly build repo.) After much
> confusion, I noticed that appending the following line to
> /etc/apt/apt.conf.d/01qubes-proxy fixed the issue and allowed the
> package to be installed:
>
> Acquire::https::Proxy "DIRECT";
>
> Is it intended behavior that apt-transport-https will fail in
> templates by default? If so, no workaround appears to be documented.
> Is my workaround the correct one?

I see two problems here:
1. It doesn't work without that setting (it should).
2. It does with after adding that setting (it shouldn't).

Updates proxy[1] is implemented to protect users from mistakes like
using template to browser the web. The only network accessible from
template should be package repositories. This apparently doesn't work in
this case. Updates proxy is a simple http proxy with whitelist designed
to pass anything that looks like yum/apt repo access. But if the
connection is encrypted, it can't check that, as the only not encrypted
part is host name, not a full URL, of course. As the most repositories
are accessible over plain HTTP, this works pretty well - repository data
is signed anyway, so it doesn't pose significant security threat[2].
The only place where HTTPS is used to access package repositories in
default install, is metalink access for Fedora template (and dom0). So
our whitelist includes that host (mirrors.fedoraproject.org).

In your case it would require adding https://repo.tox.im/ to the
whitelist (/etc/tinyproxy/filter-updates in whatever proxy VM used by
the template - whonix-gateway in your case most likely). I don't know
how to do it more in more generic way. Listing all the https
repositories is not an option of course, but listing regexp like repo.*
would be too broad IMHO.

The other problem is that you can access the repository without using
proxy (that "DIRECT" setting) - it should be blocked. This is because
currently qubes-firewall is not compatible with whonix-gateway and it is
disable there. So nothing enforces that policy on whonix-connected
templates. Patrick, do we want to fix it somehow? I see two options for
that:
1. Implement whonix-specific solution, like blocking outgoing access
(all but proxy) in the template itself
2. Rework qubes-firewall to be compatible with other firewall settings -
Whonix one in this case (use -j RETURN instead of -j ACCEPT, do not
override main chains, etc).

The first option would be safest in terms of potential fatal regressions
(leaks). But the second option would be more flexible - for example it
would be possible to use qubes firewall settings on Whonix workstation
VMs - which is sometimes a requested feature. Currently the only way to
achieve this, is to add additional ProxyVM between AnonVM and Whonix Gw.

Alternatively we can leave it as it is, and add such info somewhere in
the documentation. And probably disable updates proxy on
whonix-connected VMs.

[1] https://www.qubes-os.org/doc/SoftwareUpdateVM/#updates-proxy
[2] But using HTTPS for repository metadata has some advantages - for
example it would be harder to hold the user from updating their system
(for example by replaying old metadata).

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCAAGBQJVqmwtAAoJENuP0xzK19cseQoH/RC4lMJkIpkVzYeMY72jDDUI
PUqtb/YABWCZVFyvlWc3YBlK/Fu8uzrOr8YTOmTnPswhtKnqNZ+fBQ0zwO0RnH/O
ApKJGI3lQu6xBOI0kjIspaupnwVF0TKN3SugPyEfZoCreC0ZSytRYAjB/o7w+U8k
8YkqFMPRk6NY23axqsbLx6hp4aURzWUvyYiiFG0Wp94zYHNUtmru0QWKMRf/LSv5
OIPfiR6ns0OaIwCWtoyDqw/XGh/CbpMROGh+cuzmG9T8O9M96sw9ZqYPt7w8Jtek
DictRhHfFJJYB5+ANCLVJevAwYtV5t7GCX6xKjCF1zrQZpqrtKx0DVXraWiOvHU=
=Oemh
-----END PGP SIGNATURE-----