What updates traffic can network observers see when proxy set to TOR?

iobkvc · August 9, 2025, 2:12am

I’m looking for information about what my ISP can see while my Qubes connected to clearnet fetches repository metadata as they check for any updates available. I found such a topic on github

github.com/QubesOS/qubes-issues

Some users think that enabling updates over Tor in the installer will route all update checks over Tor

opened 02:38AM - 15 Aug 24 UTC

andrewdavidwong

C: installer P: major ux privacy C: Whonix needs diagnosis C: updates affects-4.2 community template

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) #…## Qubes OS release 4.2 ### Brief summary In the installer, there's an option to "Enable system and template updates over the Tor anonymity network using Whonix." Some users mistakenly understand this to mean that all update *checks* will also be done over Tor (via `sys-whonix`), when in reality only actual updates are done over Tor. ### Steps to reproduce During Qubes OS installation, select the option to "Enable system and template updates over the Tor anonymity network using Whonix." ### Expected behavior Some users expect that update *checks* will go over Tor, not just the actual updates themselves. Examples: - https://forum.qubes-os.org/t/24325 - https://forum.qubes-os.org/t/28235 - https://forum.qubes-os.org/t/974 ### Actual behavior Only the actual update happens over Tor. ### Possible solutions - Make it so that selecting "Enable system and template updates over the Tor anonymity network using Whonix" also causes all update *checks* to go over Tor. - Preserve the current behavior, but update the software UX and documentation to make it clear how things actually work and why. Also, implement https://github.com/QubesOS/qubes-issues/issues/7586 so that users who desire the expected behavior can configure their own systems to achieve it. Part of the reason some users have this mistaken expectation is because they believe that the only purpose of routing updates over Tor is for privacy (e.g., trying to hide the fact that they're using Qubes OS from their ISP, government, or others). From their perspective, it makes no sense to route updates over Tor while routing update checks over clearnet. They're not aware that there are [specific security benefits](https://forum.qubes-os.org/t/update-check-without-sys-whonix/974/4) to updating over Tor independent of any privacy benefits and that running update checks over clearnet doesn't detract from these security benefits. They're not aware that these security benefits (and not any purported privacy benefits) were the primary motivation for the implementation of this feature, which is why it currently works the way it does. If the current behavior isn't changed, then the software UX and documentation should be updated to help users to understand why it's implemented this way and thereby better set users' expectations. This is primarily a UX bug, but the resolution need not be purely a UX solution.

And comment by user marmarek (Marek Marczykowski-Górecki):

Another comment is that “updates check” is very different from “downloading updates” in terms of what info a network parth observer gets. With updates check, only repository metadata gets downloaded, which at most leaks info what distribution one uses (depending on some details, it could be just “some Debian”, or “Debian version X”, and that qubes is being used due to connecting to qubes repos too). Downloading updates potentially leaks more info - careful observer may try to guess what packages are being updated. With HTTPs, exact file names should be hidden, but one can still see amount of data, and correlating that with package sizes is possible. Furthermore, targeted attacks (like preventing an update) would need to target the “download updates” stage, targeting just “updates check” is not enough. So, it’s still quite valuable configuration to route just “download updates” over Tor, while doing “updates check” using any available network.

When writing about “network parth observer” and “careful observer” did user marmarek mean my ISP?

Does my ISP, when my Qubes has connected to clearnet and is downloading repository metadata to check for updates, can only see:

a) distributions of this Qube that fetches repository metadata to check for updates?

b) information that I use Qubes because I connect to Qubes repositories?

Is this all the information my ISP sees?

phceac · August 9, 2025, 5:52am

Hello @iobkvc,

I also was interested when I read this. It does not really affect me, I believe, but this is what I thought…

An “observer” can be anywhere in the routes between your machine (M) and the remote servers you contact.

It is sure that your ISP, and all devices between M and ISP can see the most, but there can also be national and international observers who can filter and examine your packets.

Update checking will tell what OS/distribution/repositories are used by you, and how many examples of each, and when they are running. Each AppVM does a periodic check for its parent template. I think the first one is just after startup, then at the usual interval (48 hrs for fedora?)

Other traffic can maybe be correlated in time to infer the use of each machine, if they are networked - clearnet DNS requests, HTTPS, etc. For example, a Debian update check just before connecting to the sports TV website - that is the football VM. This is easier if specific repositories are used per templateVM.

If you do use your ISP DNS, then it could play with TTL of different responses, for extra profiling, if there are mirrors without DNSSEC, but that seems unlikely and would be easy to detect, if we looked for it.

When you do updates, the sizes and order of downloads can reveal what packages are being updated. This is where the connection can be interfered with - for blocking security update. This is done only by templates and standalones, normally, but if you use e.g. Chrome browser only for sports TV, then there is a little bit more information there about template<->VM relationships.

One must be very interesting for the ISP to be interested in all this.

Not sure for me:

DNSsec - where it is used, checked…
Plain DNS vs DNS over HTTPS/TLS - trust ISP vs trust Google/Cloud flare/who else?
Is it time to get VPN everywhere?

adw · August 9, 2025, 9:26am

Your ISP is one example of a network path observer, but there could be others, such as governments, other corporations, and hackers – basically anyone who has access to the servers and networking equipment through which your traffic flows.

Atrate · August 10, 2025, 7:19pm

You can install Wireshark in sys-net and observe all the traffic that goes through. If you’ve never used it it may take a while to get used to it, but with some nice capture and display filters you should be able to only capture and display unencrypted traffic, which you can analyse by hand (there’s lots of guides to Wireshark available online).