@unman wrote:
Tor, but no Whonix - far too much of a hog
here: Unman's Qubes Live - #3 by unman
What are the implications of running Tor + debian-minimal as opposed to
whonix-gw? I couldn’t find any Qubes specific instructions on how to set
that up … do they exist?
Hey @Sven,
My immediate impression is that it may not sufficiently Torify all connections, which is one of the main features of Whonix, at least not without some customization of debian-minimal to do so (such as with apt-transport-tor for Torifying updates, also discussed on Whonix Wiki). I suppose that this can be mitigated by using whonix-gw/sys-whonix to proxy debian-minimal’s networking, but that involves using Whonix at some point anyway, so why not just use it as the VM running the Tor browser?
Secondly, while Whonix’s VM fingerprint may be unique, this uniqueness also means that running Tor in a non-Whonix VM will carry with it a different fingerprint that can be used to differentiate you from other Tor users on the basis of virtualization and VM distribution. I assume this applies with debian-minimal as well, even though Whonix is based on Debian. Even if Whonix’s VM fingerprint is not unique (ie it shares its fingerprint with another VM, like Debian 10), that does not mean that debian-minimal’s own unique VM fingerprint won’t still come into play.
This second problem—of shrinking the fingerprint pool—is one that Tails users also face (and Linux users generally, relative to Tor Browser on bare-metal Windows 10). Because the population of users with the same fingerprint shrinks to its most unique property, the implication of this is that the fingerprint of your activities will now ultimately be pooled among all Tor users using Tor on a debian-minimal VM (on Qubes, if the template also has a fingerprint unique from a non-Qubes debian-minimal VM), which is dramatically smaller than the already small pool of Tor users on a Qubes-Whonix VM.
I am not sure about any of this, and these are mainly speculations based on what little I know of the relevant topics, so you will probably get a much better answer from a subject-matter expert such as @unman.
Best regards,
John
I don’t understand what your “immediate impression” is based on.
Using a Tor proxy with sensible defaults will guarantee Tor connections,
and incorporating use of Qubes firewall makes it better than
Whonix-gw, which does not allow use of the Qubes firewall.
Using Onion repositories is entirely different - it has nothing to do
with sending all traffic across Tor. In fact, since the live system
can’t be updated, (because it is entirely transient), there’s little
point in using repos at all, and this is generally discouraged.
The fingerprinting issue is interesting - I haven’t seen any detailed
investigation of what the Whonix-gw and Whonix-ws fingerprint looks
like, or what other qubes look like when running through Whonix.
In any case, there are two significantly different uses of
fingerprinting - I’ve posted on this before.
One is the fingerprint that can be used to trace you : the other, the
fingerprint that can identify you once you have been found.
Using a generic qube will put you in a larger pool than using Whonix-WS
if the adversary is able to somehow compromise that qube, and read
information from it.
Using a dedicated Tor proxy will put you in a larger pool than using
Whonix-GW if the adversary is able to compromise that qube,
and read information from it. It’s arguable that it puts you in a larger
pool even if the adversary has not compromised the qube, but is simply
observing traffic.
The ease of being able to change hosts using a live version makes the
second fingerprinting method more difficult.
Whonix provides a host of stuff that a vanilla proxy doesn’t provide, e.g
sdwdate, tests prohibiting Tor-over-Tor, etc. Neither of the two
mentioned are things I want.
It’s often valuable to be able to set the time and timezone to “wrong”
values - and while Tor can struggle when the time is incorrect, in many
cases it works fine.
Similarly, the only argument against Tor over Tor was adduced by adrelanos
In my opinion, the form of fingerprinting that most users are subject to
is use, assuming they use Tor to hide their IP. This is because
people are creatures of habit - they work at much the same time
every day; visit the same websites; open a browser, and then check
their mail; use the same set of logins across different sites, (not the
same names or passwords, but the same set of logins). All of
these patterns of behaviour make it easier to limit the pool to which
one belongs, and are very difficult to break.
Qubes, whether using Whonix or vanilla Tor, makes it somewhat easier to
break some of these patterns. It isn’t easy.
Now I am even more intrigued and I remembered Joanna’s original article:
I’ll study that one more and try to replicate it. @unman is there
anything I need to pay attention to that is not covered in the above
article?
root@sys-tor:/rw/config# ./start_tor_proxy.sh
xenstore-read: couldn’t read path qubes_ip
./start_tor_proxy.sh: 6: [: X: unexpected operator
Mar 05 18:53:36.211 [notice] Tor 0.3.5.12 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Mar 05 18:53:36.211 [notice] Tor can’t help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Mar 05 18:53:36.212 [notice] Read configuration file “/etc/tor/torrc”.
Mar 05 18:53:36.214 [warn] Skipping obsolete configuration option ‘TransListenAddress’
Mar 05 18:53:36.215 [warn] Failed to parse/validate config: Unknown option ‘9040’. Failing.
Mar 05 18:53:36.215 [err] Reading config failed–see warnings above.
Error starting Tor!
./start_tor_proxy.sh: 23: echo: echo: I/O error
./start_tor_proxy.sh: 31: echo: echo: I/O error
… alright. Let the fun begin. 
… I thought so.
… although I seem to be unable to reach qubes.i3sec.org
… because it’s 3isec.org duh
… and it is done! My understanding is that this used to be qubes-linux-tor, which was deprecated in favor of whonix. But @unman is keeping it alive as 3isec-tor. Many thanks!
Has to be said, I haven’t looked at that for a while, so cant guarantee
it in any way. I should check it against my own repo and push any
needed updates.
If you want a working Debian package, I can put one up if its not already there.
Note that Whonix is the officially endorsed solution for Qubes.
In my opinion, the project is trying to do far too much. But in any
case, Whonix is just not an option in a live Qubes system, where you
have to conserve space and RAM as far as possible. (I believe there is
a separate Live Whonix - I haven’t tried it and don’t know the state of
that project.)
I was actually thinking about how to automate the building of the template. In this first iteration I went with your deb package from qubes.3isec.org … but I could also simply clone your repo and call make myself? … I’ll try
I’m pretty confident that Make wont work - but building a Debian package
will.
deprecated and removed.
Re: “depricated and removed”
I know you like to be brief, but for the sake of clarity: you mean the official qubes package, while you continue to host 3isec-tor – correct?
I understand the “so cant guarantee it in any way” part and that it’s my responsibility to understand what the code does and whether I’d like to use it.
The one that’s there works fine – thank you!
Yes , I host
What I cant guarantee is that GitHub is up to date. The TorVM is fine.
Hello @unman,
Thank you for critiquing my reply. It was illuminating and helped rectify some of my ignorance on these matters, as well as properly address the topic in a way fitting for a Qubes environment. I am still very new to Qubes OS, both technically and conceptually, and it is that to which I attribute my error.
Briefly, I will explain the basis for my impressions in the context of your reply. I attempted to avoid any assumptions about VM proxying or additional Qubes VMs because @Sven’s original question made no mention of them, instead only asking about a comparison between two VM configurations. Perhaps I interpreted the question and in particular “Tor” too narrowly as being within the debian-minimal VM, which is entirely the fault of me not “thinking with Qubes.” This is why I mentioned Torifying updates from within the debian-minimal VM, since the much more elegant solutions you provided involved a more “Qubic” approach, which admittedly is the correct one (especially on Qubes OS!).
I have no comments about the rest of your explanation, only gratitude that you provided it for all of us to learn from.
Thanks,
John
P. S. It appears I’m late to the party. I’ve been very busy this week, so haven’t had the time to reply. Apologies for that. I wanted to acknowledge unman’s contribution, which I think does a much better job at addressing the topic than mine does, but I see this post is rather superfluous at this point. My fault for not finishing the thread before posting. 
Reporting back after a few days of use. The TorVM as provided through @unman works perfectly and with very few resources. Allow me to post the commands I used to setup the respective template:
qvm-clone $1 $2
qvm-copy-to-vm $2 ~/.config/conf/unman.asc
qvm-run --pass-io -u root $2 “apt-key add /home/user/QubesIncoming/dom0/unman.asc && rm -Rf /home/user/QubesIncoming”
qvm-run --pass-io -u root $2 ‘echo “deb [arch=amd64] http://HTTPS///qubes.3isec.org/4.0 stretch main” | tee -a /etc/apt/sources.list.d/3isec-stretch.list’
qvm-run --pass-io -u root $2 “apt update && apt install --no-install-recommends qubes-core-agent-networking 3isec-tor -y”
qvm-shutdown --wait $2
qvm-features $2 qubes-firewall 1
I don’t know the discussion and arguments that lead to deprecating and removing qubes-linux-tor, but I wish it would continue to be officially maintained and provided as an alternative to those who would like to use it. Luckily, we have @unman – thanks again!
Update (3/14/21): the torproject signing key is also needed and must be added the same way unman’s key is. I found it rather challenging to verify the key. Here is the one I am using (hoping it’s the right one):
pub rsa2048/EE8CBC9E886DDD89 2009-09-04 deb.torproject.org archive signing key
Primary key fingerprint: A3C4 F0F9 79CA A22C DBA8 F512 EE8C BC9E 886D DD89
@unman would it be possible in a future version to include the torporject.org signing key in your deb package? That way one has to only find and verify your key.
hi @unman,
is 4.0 stretch still the repo to use for your TorVM?
doing a test install now in debian-10-minimal, but wondering if there is an update, or a plan to move it into 4.1 repos on qubes.3isec.org
thanks!