Credit to @tasket @rustybird for highlighting the issue. (can't find the post) Just remembered: https://github.com/rustybird/qubes-updates-cache
- 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
## 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.