Prevent Qubes OS clearnet leaks

Community Guides
41

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.
42

Please elaborate.

43

Some example …

https://www.sciencedirect.com/science/article/abs/pii/S0957417424004093

https://www.infosecinstitute.com/resources/machine-learning-and-ai/deanonymizing-tor-using-ml/

Thanks, but no thanks [Kudos to Qubes and Kicksecure/Whonix, but not confident enough to use them]
44

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.

45

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.

46

Please elaborate.

Ditto.

@unman has asked for evidence on various things among threads, now here is a bold claim without one.

2 Likes
47

I was going to make a snarky comment to match yours, but perhaps you
dont know what terms to use to make a good search.

There has been a lot of research for many years focussing on Tor traffic.
Some on identifying Tor and obfuscated Tor, within normal streams. Some
on identifying the type of traffic within Tor streams. There’s already
significant work on identifying content within encrypted schemes.

There’s an interesting paper from 2022 that suggests approaches to
traffic analysis that allow for accurate identification of malware
communication in Tor. Not only were they able to identify the malware,
they were able to identify the class of malware from within the Tor
traffic.

Priyanka Dodia, Mashael AlSabah, Omar Alrawi, and Tao Wang. 2022. Ex-
posing the Rat in the Tunnel: Using Traffic Analysis for Tor-based Malware
Detection. In Proceedings of the 2022 ACM SIGSAC Conference on Computer
and Communications Security.

For a good overview of the field, there’s a literature review from 2024:
J. Saleem, R. Islam and M. Z. Islam, “Darknet Traffic Analysis: A Systematic Literature Review,” in IEEE Access, vol. 12, pp. 42423-42452, 2024, doi: 10.1109/ACCESS.2024.3373769.

This contains excellent summaries of different approaches taken, as well
as (naturally) references to other papers in the field. Definitely a
good place from which to start.

Once you dig in to this you will see that there is considerable work
being done on identifying traffic patterns of specific web sites, and
complex behaviors. In this thread there has been reference to specific
behavior of Qubes and Whonix, and these could be used to fingerprint
Qubes and Whonix users even if they have configured their systems
to run entirely across Tor.

The Tor project line on this seems to be that it’s all academic, and overstated.
Whenever I read this sort of criticism, I always think of Clifford Cocks.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

5 Likes
48

@unman

Excellent feedback. Thank you.

So, considering all that, what would you recommend? Stay away from Whonix? Any replacement? Another approach?

49

Thanks

There will always be uncertainty here. I raise this to make it clear
that there’s no magic bullet. You can take steps to reduce leakage, and
route everything through Tor or i2p, and do the best you can, but it may
not be enough.

As James Mickens so rightly said -
“If your adversary is the Mossad, YOU’RE GONNA DIE AND THERE’S NOTHING
THAT YOU CAN DO ABOUT IT.”
Do the best you can.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

50

As James Mickens so rightly said -
“If your adversary is the Mossad, YOU’RE GONNA DIE AND THERE’S NOTHING
THAT YOU CAN DO ABOUT IT.”

“Mossad will do mossad things”[1]

Footnotes:
[1] https://www.usenix.org/system/files/1401_08-12_mickens.pdf

1 Like
51

@unman

There will always be uncertainty here. I raise this to make it clear
that there’s no magic bullet. You can take steps to reduce leakage, and
route everything through Tor or i2p, and do the best you can, but it may
not be enough.

It is great that you remind community members that.

I remember you mentioning that you don’t use Whonix. Is that related to what you are saying here? What are the pros and cons of your approach?

Do the best you can.

The question is what is best (or rather: what makes sense).

Personally, I still don’t understand what are the particular clues that an adversary may use to identify that e.g. a curl HTTP request is made from a Qubes OS domU or from bare-metal Debian, assuming the same curl binary is in use.

Can anyone clarify that or point me to a thread explaining it?

52

Sometimes Mossad agents are the ones who die, or are about to die if they aren’t exchanged for something valuable soon enough. What’s happening in Iran right now.

53

I do not use Whonix. I do use Tor and I2P.

The thread started with avoiding clearnet links and the underlying aim
was about hiding the use of Qubes. I’ve somewhat extended
that to “hiding use of Qubes, Tor, and Whonix.” A single request from a
qube is not enough for that. What will reveal is patterns of behavior
(personal and system) and (perhaps) links to endpoints.

System behavior - candidates could be those patterns peculiar to
Qubes/Whonix. Time connections, update checks, end point access. This is
why ( a long time ago) I suggested turning those off in clearnet. You
may want to turn them off altogether.
In some cases a determined adversary would be able to note traffic to
Qubes update mirrors. Another flag might be traffic from a Fedora host
to Debian update mirrors. In most cases there will be no magic bullet
that can be used to identify, but a pattern of behavior, which may be
identifiable whether in the clear or through Tor. Updates and templates
will carry identifiable characteristics, and will be known to the
adversary.
We have had some success in identifying Qubes and Whonix hosts through
traffic analysis. Tor through Qubes is more difficult to distinguish
from “normal” Tor, so with reasonable opsec you would be part of larger
community than that of Qubes/Whonix users.

I would say (again) that most users who are concerned about security and
privacy are far more likely to make mistakes in use than to be let
down by Qubes. For many users, the best thing to do is to use Qubes
defaults and to focus on hardening the system using existing tools, like
policy settings, and to learn how best to take advantage of the
isolation that Qubes offers.

I never presume to speak for the Qubes team. When I comment in the Forum I speak for myself.
5 Likes
Counterpoints - Why Anonymity No Longer Exists in 2026
54

@unman

Thanks.

I do not use Whonix. I do use Tor and I2P.

I know that as you have mentioned it. I am asking something more about it, if you could provide info. That is interesting, as it is obviously an alternative and from your explanation it sounds it makes the user less identifiable.

patterns of behavior

I guess that applies to any OS.

I thought you may be referring to TCP/IP stack fingerprinting rather than behavioural pattern detection. Is there anything that makes Qubes identifiable in regards to it? Or (looking further up the stack) would you say a browser running in a qube reveals that the OS is Qubes (and not the OS of the template)?

System behavior - candidates could be those patterns peculiar to
Qubes/Whonix. Time connections, update checks, end point access. This is
why ( a long time ago) I suggested turning those off in clearnet. You
may want to turn them off altogether.

Does pinging a particular host count as end point access? I am asking because, as you know, in Qubes firewall currently it is enabled (to any host), that is hidden from the GUI and controllable only through CLI.

Disabling/Torifying time connections is tricky. Most people use a home LAN router which leaks, so I wonder what value disabling it in qubes has.

We have had some success in identifying Qubes and Whonix hosts through
traffic analysis. Tor through Qubes is more difficult to distinguish
from normal Tor, so with reasonable opsec you would be part of larger
community than that of Qubes/Whonix users.

How do you do “Tor through Qubes” as opposed to Whonix? Do you have a guide for it?

Personally, I am somewhat confused that Whonix is loaded with stuff that I can’t remove without that resulting in removing whonix- and qubes-specific system packages that seem necessary for other packages:

# apt-get autopurge thunderbird
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  libotr5* python3-numpy* python3-qubesimgconverter* qubes-gpg-split*
  qubes-img-converter* qubes-pdf-converter* qubes-thunderbird* qubes-whonix-workstation*
  qubes-whonix-workstation-packages-recommended* thunderbird* thunderbird-qubes*
0 upgraded, 0 newly installed, 11 to remove and 0 not upgraded.
After this operation, 312 MB disk space will be freed.
Do you want to continue? [Y/n]

Things like that are basically forcing me to use a non-minimal system with packages that I never use, to update them etc.

55

dummy-dependency

1 Like
56

I have a package that you can install on a debian-minimal template. It
will set up the Tor repo, signing key, and install Tor and nyx. You can
get it by following the instructions here to set up the repository,
and install the 3isec-tor package.
After installation apt update and apt upgrade to get the latest Tor
version from the Tor project.
Close down the template. Create a new qube using it, set
provides_network True in the preferences, and enable the service with
qvm-service --enable 3isec-tor. Set it as netvm in downstream qubes.
You’ll find that you can run the Tor qube with low memory requirement.
It supports qubes firewall.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

3 Likes
57

@linuxuser1

Thanks! I didn’t know that.
So, I should do this:

dummy-dependency --yes --purge thunderbird

Correct?

58

@unman

Thank you. That is very interesting.
Why isn’t your package part of official Qubes instead of Whonix?

59

It used to be an official package.
If I remember rightly there was a perception that updates through the
TorVM were badly affected, and Whonix was seen as the solution. Ironic
really.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

2 Likes
60

@unman

If I remember rightly there was a perception that updates through the
TorVM were badly affected

How come? What makes Whonix better in regards to it?
And what is necessary to fix it, so that it becomes the official thing again?