Improve apt-get stream isolation


Credit to @tasket @rustybird for highlighting the issue. (can’t find the post) Just remembered: https://github.com/rustybird/qubes-updates-cache

  1. For Tor users, the remote network has some insight about what’s installed on the same physical computer, because there is no Tor circuit isolation between update requests from different clients. This can be prevented by waiting at least 10 minutes (or sending NEWNYM) between updating different clients. (The same is true of qubes-updates-proxy.)

Desired behavior: apt-get should use new circuits for each client VM and also use new circuits for each repository. In non-Qubes-Whonix, multiple VMs that perform apt-get update use different circuits because of IsolateClientAddr. In Qubes-Whonix, all TemplateVMs share the same circuits for apt-get (due to Update Proxy design?).

Current observed behavior: Circuit A is used to route traffic for all apt-get requests from all TemplateVMs going to vwakviie2ienjx6t.onion. Circuit B is used for all traffic going to sgvtcaew4bxjd7ln.onion. Circuit C is used for all traffic to clearnet repos, including qubes-os.org, whonix.org, and 3rd party repos. These potentially allows for some linkability between TemplateVMs - both by the Exit Node as well as by the repository server.

I don’t know enough about tinyproxy (or http proxies in general) to propose a solution. Some possibilities:

*1. (For non-Qubes-Whonix) Enable IsolateDestAddr for apt-get port. From /usr/share/tor/tor-service-defaults-torrc:

## Operating system updates: apt-get
## Not using IsolateDestAddr IsolateDestPort, because too much
## performance loss, too much load on Tor network and no gain
## in security.

This was probably written pre-Qubes. Enabling IsolateDestAddr will cause an extra tor circuit per clearnet repo - not too much load. And no additional load if using .onion repos which are isolated by default. This would fix per-repo isolation but not per-client isolation.

! This doesn’t work for Qubes-Whonix because uwtwrapper is disabled for apt-get. Instead apt-get requests are sent to tinyproxy port 8082 and then sent to Tor via (TransPort???). Can we spin the packet around and have it route through a SocksPort?

*2. (For Qubes-Whonix) Somehow masquerade Source IP so that IsolateClientAddr is activated.

*3. (For Qubes-Whonix) Somehow enable SOCKSAuth so that some category of apt-get request is assigned a random SOCKS password.



If all TemplateVMs use the same sys-whonix as their NetVM, unfortunately yes.

Was written pre-Qubes indeed.

More than that.

When you connect run nslookup ftp.us.debian.org for several times, you get several results. DNS round robin. It’s actually multiple servers. Each apt-get package download is a separate fetch. So it would be one circuit per resolved ftp.us.debian.org IP when multiple packages are downloaded.

I agree we should revisit this. Can you please ask on tor-dev if it’s fine for Whonix to use IsolateDestAddr IsolateDestPort for its apt-get Tor SocksPort?


I wouldn’t know how. That would be preferred. However, tinyproxy does not support socks proxy settings, which would be a lot better. It just uses normal networking ("speaks only trans"). It runs under its own linux user account at least which might make things easier.

The question you are asking is generally a hard one. How can one force an arbitrary application that does not support socks proxy settings through a socks proxy. Well, there there are proxifiers / socksifiers such as torsocks (and uwt scripting it). But that probably won’t work with tinyproxy.

sudo su
torsocks /usr/sbin/tinyproxy -d -c /etc/tinyproxy/tinyproxy-updates.conf

/usr/sbin/tinyproxy: Could not create listening socket.

One cannot socksify an application as well as at the same time have it open a listener port using a socksifier.

redsocks might be worth exploring.

(There is some information on redsocks here - although it’s on a different topic you can see the idea - https://www.whonix.org/wiki/Tunnels/Connecting_to_Tor_before_a_proxy#Transparent_Proxying_Method.(

Although all DNS would still go through Tor’s DnsPort. [Might be fingerprintable, because TCP traffic without previous DNS request.]

Do you think qrexec based updates proxy will help with this? @marmarek


Do you think qrexec based updates proxy will help with this? @marmarek

Maybe. Connection to the “proxy” will arrive as qrexec call, stream
there will be “HTTP proxy” protocol. So, if you pass it to some “HTTP
proxy -> socks” filter (instead of tinyproxy), that would work. I think
socat can not do that, but maybe something else can?

You’ll have there name of source VM, so can use that to direct it to
isolated circuits.


Talked to Roger at 33c3: No, he prefers us not enabling that.

/usr/sbin/tinyproxy: Could not create listening socket.
One cannot socksify an application as well as at the same time have it open a listener port using a socksifier.

This might be possible in Debian stretch based Whonix 14. torsocks learned AllowOutboundLocalhost 1, which will be enabled by default in Whonix 14 in the uwt package.