It’s almost impossible to do this with a well funded and capable
upstream. Not just Qubes - Whonix and Tor use are all identifiable.
A lot of work has been done on monitoring encrypted channels, and it is
possible to identify content in Tor streams.
If you want to avoid clear net activity, do so. If you are concerned
about connections in update checking, then do not run qubes in the
clear. But be aware that this will not provide you with absolute safety
and will likely draw attention.
A reasonable alternative would be to modify qube creation to
automatically turn off update checking after creation. (script or
salt.)
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I believe to have an opsec setup that protects me from that: my tor stream is encapsulated within one or more encrypted channels to anonymous hops. These streams of traffic are continuously active, though their volume may fluctuate a little. Even if this traffic is monitored from the ISP to the primary hop of the chain, it would be difficult to separate the tor traffic from the other types of traffics because they are all encapsulated together under one or more layers of encryption. This traffic might look a bit odd, but how many people are watching netflix for many hours a day under a vpn ? a lot.
I’d like to know if I’m wrong and why.
Only something capable of monitoring the whole traffic moving from hop to hop would eventually figure out I’m using tor underneath.
I’m still using private obfs4 bridges, considering they are encapsulated like I said above I dont feel the need to switch to more “traffic benign looking” bridge types.
I’ll just disable qubes-update-check.service in all templates. I still have to test it but I think it should work.
i2p is on its face a better protocol than Tor. The coordination (even if centralized) that Tor has but applied to i2p would probably be a lot better. A delay-oriented protocol used to fetch contents by identifiers (which could be hashes) instead of a synchronous/stateful protocol (HTTP on TCP) rather than by “location” (hostname / domain name) running on i2p would avoid many of the practical and theoretical problems that Tor has.
I write “probably” because the topic of deanonymization attacks on Tor circuits requires significant attention. But no one has to be an expert or even have had invested deep research to see that i2p has something that is better.