Whonix Desktop (temporary name), based on the “Hardened Debian” project, and currently available for building as whonix-host-xfce flavor, is designed to be installed on physical hardware to act as a hardened debian host system.
The purpose of Hardened Debian/Whonix Host is not anonymity, but security. With that in mind, it could be even dangerous for some users to have Tor and Whonix services autostart on boot. In some cases, it could lead them to prison or serious problems (thinking about particular places where Tor is forbidden or a big red flag)
If they need Tor, they have the (already installed and configured) Whonix VMs with virt-manager at their disposal, working out of the box.
Otherwise, we should assume that the user installing Whonix-Desktop on hardware does not want to have any Tor or other potentially suspicious networking or Whonix-related activity going on on his main machine without his explicit consent and activation.
Therefore I suggest to remove these packages from the Whonix-Desktop build, or at least disable them.
I didn’t follow all the discussions and perhaps am a bit confused here, but my understanding is that hardened debian is one project (indeed focused on security) and the whonix desktop / host is another, which was created to provide an easier integration of the host (the hardened debian, in fact) with the virtualizer and the VMs as we know them today. If that is so, there is no real reason to have Whonix desktop / host without Tor.
Users that don’t need / face risks having Tor should only use the Hardened Debian, not Whonix desktop.
Exactly. Reason is that Tor services are already provided by the VMs, but should not be enabled on the host unless the user specifically wants it. If not installed, can be installed by the user at any time. Should be a choice, not a prerequisite. I know of many use cases where using Tor/Whonix-related activities automatically on the host would be a problem/danger.
As far as I know, Hardened Debian also contains Tor/some Whonix-related packages. Thus my proposal.
Ok, I wasn’t aware of that. If you specifically refer to not having Tor / Whonix as default on the Hardened Debian, makes more sense for me.
Not depending on updating from whonix sources is also a security advantage.
I have just installed Whonix Desktop (based on Hardened Debian) using the ISO with Calamares. These are the services running (all natively installed except spice-vdagent - I am running this in KVM):
root@whonix-desktop-pc:~# cat /var/log/syslog | grep -i onion
May 15 15:09:15 whonix-desktop-pc Tor[762]: The current consensus has no exit nodes. Tor can only build internal paths, such as paths to onion services.
May 15 15:09:21 whonix-desktop-pc sdwdate[806]: 2019-05-15 15:09:21 - sdwdate - INFO - Requested urls ['secrdrop5wyphb5x.onion', 'xmrto2bturnore26.onion', 'earthqfvaeuv5bla.onion']
May 15 15:09:28 whonix-desktop-pc sdwdate[806]: 2019-05-15 15:09:28 - sdwdate - INFO - Returned urls "['secrdrop5wyphb5x.onion', 'xmrto2bturnore26.onion', 'earthqfvaeuv5bla.onion']"
May 15 15:09:28 whonix-desktop-pc sdwdate[806]: 2019-05-15 15:09:28 - sdwdate - INFO - remote 0: secrdrop5wyphb5x.onion
May 15 15:09:28 whonix-desktop-pc sdwdate[806]: 2019-05-15 15:09:28 - sdwdate - INFO - remote 1: xmrto2bturnore26.onion
May 15 15:09:28 whonix-desktop-pc sdwdate[806]: 2019-05-15 15:09:28 - sdwdate - INFO - remote 2: earthqfvaeuv5bla.onion
May 15 15:09:29 whonix-desktop-pc sdwdate[806]: 2019-05-15 15:09:29 - sdwdate - INFO - Pool 1: secrdrop5wyphb5x.onion, web unixtime: 1557922170, web time: Wed May 15 14:09:30 UTC 2019, diff: -3599 seconds
Ok, I must be missing quite a lot here then.
Different sdwdate’s run both on the host and inside the VMs?
Doesn’t Tor in both places together lead to similar issues as with multiple gateways running in parallel?
Currently already the case for both, hardened debian and Whonix host.
Disadvantage being that we have to,
install anon-connection-wizaard on the host too. (And then have user duplicate that work inside Whonix-Gateway.) [In theory, OneVM where Tor runs on the host would make more sense to avoid duplicate Tor config and duplicate Tor connections but OneVM may also be harder to get right in terms of leak protection, never thought that through.]
drop “give user option to not connect to the public Tor network”.
So we have to choose between:
no secure time sync by default
use NTP
or use nonthing?
drop “give user option to not connect to the public Tor network”
two Tor running by default (host and Whonix-Gateway)
OneVM alike (unrealistic mid term and perhaps even unrealistic ever?)
A related question:
I’ve head this before and acted as if it is true. Is there actually any evidence for that?
Does even The Tor Project with TBB connection wizard (tor-launcher) address the hiding Tor use case or only the censorship circumvention use case? It looks to me like the latter.
Being founder of Whonix project shouldn’t prevent me from asking learning questions. I’ll direct less energy on appearing professional and rather spend energy on getting better. I build Whonix which incorporates Tor but that doesn’t make me perfectly knowledgeable on the state of everything related to it such as in which countries it’s super dangerous to use.
In countries so draconian, does one already attract attention by being a Linux on the desktop user? Desktop use is less and less. Linux on desktop computer are few in numbers. Debian users then are a minority compared to Ubuntu users. Linux users are even fewer in draconian countries. So if singling out users is the goal, isn’t being a Debian at home desktop computer already so far away from mainstream people that this alone is suspicious enough?
Users of hardened debian and more so users of Whonix host are clearly users of the software by the Whonix project which is related to Tor. By following the quoted assumption, one could argue that using Whonix host and/or using hardened debian alone would put users at risk. (They’d be using Whonix repository.)
The current state of Hide Tor and Whonix ™ use from the ISP is really meager. It looks so difficult that I wonder if anyone is able to act good enough to actually hide Tor and Whonix from the ISP.
How does a first time user in such an area learn about Tor without getting suspicious learning about Tor?
They’ll then get TBB and private obfuscated pluggable transports (bridges), then download Whonix and set up private obfuscated pluggable transports (bridges) there too?
Where they’ll get the private obfuscated pluggable transports (bridges) from in first place?
I find this rather unrealistic. There may be a few users which manage to pull that off but perhaps that is in the single digits area?
Some pluggable transports may seek to obfuscate traffic or to morph it. However, they do not claim to hide that you are using Tor in all cases but rather in very specific cases. An example threat model includes a DPI device with limited time to make a classification choice - so the hiding is very specific to functionality and generally does not take into account endless data retention with retroactive policing.
Furthermore, by adding more and more Kernel Hardening - security-misc, we could likely introduce a network fingerprint which is unique to Whonix. Do we want to be less hardened and maybe not fingerprintable as Whonix users or do we want to be more hardened and more likely fingerprintable as Whonix users?
The state of censorship circumvention in Whonix is unfortunately very limited anyhow. Anon connection wizard (frontend) is not being worked on, and the state of pluggable transports (backend) (the newest aren’t available outside of TBB anywhere as far as I know) doesn’t look better too.
The more I am thinking about it the more I am thinking “censorship circumvention may be possible but hiding Tor is unrealistic and should not be relied on”.
All of this mess makes me wonder if it would be best to tell such users “sorry, too difficult, we can’t help, go somewhere else”.
It wouldn’t surprise me if certain countries would imprison you for using Tor. Especially countries where hardly any information about the goings on there gets out (e.g North Korea). I’ve had someone on Reddit tell me they lived in one of those countries and using Tor would get them imprisoned. They may have been one of those people thinking the “spooky deepweb” was illegal but I don’t think so.
I think Linux would attract attention. It seems it already does attract attention from the NSA as they label visitors of Linux Journal as “extremists”.
If this is in the US, then imagine what countries like Iran would be like.
Only certain network hardening options will affect the network fingerprint but many people use these anyway as they’re basic hardening. I doubt these will single out Whonix users but if Whonix does more network hardening then it might.
It could be possible to have 2 builds. One for security and one for hiding Tor/Whonix at all costs. Or even add this as a boot parameter.
Russia for instance has banned Tor and VPN. I don’t know whether it is enforced or not. But it sure will be used against you if they need to pressure you. My point is: you could have very compelling reasons to not want to start any Tor activities unless you specifically want it. By torifying the host/starting Tor services by default we basically deprive the user from this choice.
I don’t know, maybe it could be, maybe not. But this is not within our control. We are powerless if using Linux is already suspicious or even dangerous. But starting Tor activities on boot is a choice we make for the user - and we can chose not to do so.
Whonix repositories are indeed a problem in this perspective. In your opinion, would it be possible to remove Whonix repositories from the the Host without breaking functionality? And if no, which ones could cause problems?
It seems a bit drastic to me.
In my understanding, we offer the following solution:
a bootable ISO, basically a hardened debian, with Whonix Gateway/Workstation VM on virt-manager for amnesic use
this same ISO gives the user the possibility of installing the same system on hardware, to benefit from the same settings and config
Nothing more, nothing less.
This is why I don’t see many advantages of torifying/enabling Tor services on the Host. All Tor activities should be done in the Whonix VM (it’s their purpose, after all), if and when the user chooses to do so.
security-misc seems to be a big part of Hardened Debian/Whonix Host so this doesn’t seem possible to remove without decreasing security a lot. The files could be included by default but then it can’t be updated.
Indeed, if they can’t be updated the whole concept of shipping a hardened debian derivative is useless.
Maybe some kind of mechanism where apt update doesn’t fetch them by default but only when run with a specific flag? Is this even possible without being too complicated?
Just wanted to add a practical example (mine).
I have a laptop with debian stable as host. Fortunately, I don’t have to care whether I am identified as a Linux/Debian user or not (to the point where I never really investigated the matter, btw would be nice if you could share some info on this topic, what more singles out a Linux user, other than fetching repositories and browser fingerprinting?)
But I do happen to travel with this laptop, and maybe I am paranoid, but I really don’t like the idea of having my computer constantly connecting to the Tor network without any sort of control. This is why Tor is not installed on my host, only in virtual machines or Whonix.
I would certainly not feel comfortable would it be otherwise. I don’t see the point of torifying my host - on the contrary it should look as benign and harmless as possible IMHO.
Packages can be prevented from updating by “holding” them. This just tells apt not to update it. You can hold a certain package by running echo (package) hold | dpkg --set-selections. Replace (package) with the package you don’t want to update. In this case it would be security-misc.
You could then create a simple bash script that updates your system and unholds when a certain flag is run and keeps it “held” every other time.
There are many ways to identify a Linux system. For example, your TCP/IP stack fingerprint can detect your OS. See My IP Address - BrowserLeaks and look at the “TCP/IP Fingerprint” part.
If an attacker has access to your system then it’s extremely easy to figure out what OS it’s running.
This shouldn’t matter that much. If you really want to then you can just disable Tor when you don’t use it. Run systemctl mask tor and it will prevent Tor from ever running unless you unmask it.
Another way to single out a Linux desktop users: At boot time they don’t
have the usual Windows update and other Windows phone home traffic.
onion_knight via Whonix Forum:
Russia for instance has banned Tor and VPN. I don’t know whether it is
enforced or not.
Blocked or banned is also a difference.
I don’t know, maybe it could be, maybe not. But this is not within our control. We are powerless if using Linux is already suspicious or even dangerous. But starting Tor activities on boot is a choice we make for the user - and we can chose not to do so.
I would like to avoid spending significant effort on “operation
succeeded, patient dead” style work. If what we produce (Linux desktop,
hardened by default) already attracts attention above threshold
(unwanted visitors), then not connecting to the public Tor network
doesn’t make any difference in practice either.
Whonix repositories are indeed a problem in this perspective. In your opinion, would it be possible to remove Whonix repositories from the the Host without breaking functionality? And if no, which ones could cause problems?
Certainly possible to remove but not possible without breaking upgrade
functionality.
[1] Also removal of Whonix repository doesn’t help: the list of
installed packages is specific to the distributor (Whonix) and leaks
when using apt-get over clearnet. Any linux distribution redistributed
by Whonix will be tied to the Whonix project.
This is why I don’t see many advantages of torifying/enabling Tor services on the Host. All Tor activities should be done in the Whonix VM (it’s their purpose, after all), if and when the user chooses to do so.
Maybe some kind of mechanism where apt update doesn’t fetch them by
default but only when run with a specific flag? Is this even possible
without being too complicated?
Adds a lot extra complexity for a minority use case that may be in state
“operation succeed, patient dead”. Hard to test upgrades with one who
uses apt-get hold vs apt-get non-hold.
And then also what we’d document? “Some packages don’t get upgraded by
default because we want to hide Tor by default. If you want to upgrade
all packages while hiding Tor, enable Whonix repository and upgrade over
Tor when using precautions to hide Tor.” Sounds too geeky. Also “why I
don’t get upgraded”, “well, you need to enable Whonix repository first
but only do this if you don’t have to hide Tor”.
Due to [1] this is theoretic anyhow as there are other ways for a
network observer of a non-torified desktop operating system to find out
what “extremist” operating system is being run.
Only certain network hardening options will affect the network fingerprint but many people use these anyway as they’re basic hardening. I doubt these will single out Whonix users but if Whonix does more network hardening then it might.
subset: linux desktop users (much smaller than Windows desktop users)
subset: debian users (much smaller than Ubuntu desktop users)
subset: hardening by default (even smaller than Debian desktop users)
subset: in a specific country.
subset: in a draconian country.
So when piling up so many subsets the amount of remaining users is so
little that I would assume these get labeled “extremists” too.
Also whonix-firewall drops invalid packages. If someone wanted to probe,
an active adversary could send invalid packages and then see the
difference dropped vs non-dropped.
It could be possible to have 2 builds. One for security and one for hiding Tor at all costs. Or even add this as a boot parameter.
In theory, yes. I am happy to have this in source code, as build option,
boot option, and/or whatnot. Contributions welcome. However, I wouldn’t
be redistributing separate hide Tor by default builds. Lack of
motivation for now. We don’t hear anything from “use of Tor is dangerous
in my country” type of users, and it might be healthier to not hear more
from them anyhow. It would be a big responsibility to claim we got that
right and specifically attract these kind of users. There’s a line when
technology cannot fix social issues.
