What about the cases users need to use different gateway / tor configuration?
For example, today users can use another Gateway when using onionshare. Another disadvantage will be the lack of snapshots that makes it easier to recover from mistakes in configurations.
In general I agree with @onion_knight’s view. Whonix host as a hardened debian / pre-installed Whonix, Tor connections only within the VMs.
cant we as well separate Tor in whonix host connection from Tor in GW ?
GW has its own connection and whonix host has its own connection. so torrifying the host wont lead to TorOverTor nor oneVM connection.
That it’s the state of things anyhow. Whonix-Host and Whonix-Gateway
running separate Tor. A lot easier to implement than Whonix-Host using
Tor running inside Whonix-Gateway.
Reframing the question:
What purposes are we using Whonix Host for besides hosting Whonix VMs in a secure way?
I would argue for turning the Whonix Host into something resembling Dom0 where no internet access is possible for software running there except to update the system and keep accurate network time. Any other cleranet access by other applications will add unnecessary risk.
Since we are applying this policy to Kicksecure (with the important caveat that non anonymous traffic is allowed) this shouldn’t seem controversial a decision IMHO.
but these are mostly convinience options. More importantly will be in future a Kicksecure ISO.
Well, we can say Whonix is based on Kicksecure but Kicksecure development goal is being standalone and not reliant on Whonix software. Although Kicksecure is unfortunately still hosted on whonix.org which is due to lack of resources, non-ideal and a source of confusion.
We Torrify sdwdate and apt on Kicksecure but otherwise no traffic anonymization or restrictions are applied.
As an aside, I think a Kicksecure VM on a Whonix Host as I envision is necessary for dealing with captive portals and stubborn websites like banking that won’t accept Tor.
Kicksecure can potentially be the base for a Unistation on baremetal rather than the final end product for users.
In that case users might shoot their own feet with a Kicksecure VM?
This is specifically bad since SecBrowser in Kicksecure is still branded as “Tor Browser” (as rebranding seems not possible in an easy, reliable way without recompilation which would be too much effort).
This would lead to confusion for sure if not gotten right. Tails renamed their captive portal solution Unsafe Browser to make that clear and then users still use it for all sorts of stuff.
Also not sure yet how that would influence Whonix-Host firewall. Some VMs no connectivity (Whonix-Workstation), some VMs Tor-only connectivity (Whonix-Gateway), some VMs clearnet connectivity (Kicksecure). Related:
That was always possible. Calling it Kicksecure or not. In that case,
there wouldn’t have been any need to call it Kicksecure / renamed/restructure packages.
If Kicksecure doesn’t become an end-product for users then there’s little need for it. Was the idea behind Kicksecure. Debian based security (invented as “by-product” of Whonix development) but without focus on anonymity/privacy.
Please call for comments in the thread in addition to a poll. We can get more information on what exactly users expect.
Its important to implement VM differentiation because of this. TO-DO research on window borders, desktop wallpapers and so on,
I believe they were using vanilla Firefox as a unsafe browser base.
So here is what I mean by end product family tree:
Kicksecure base → Kicksecure VM
|
| -> Whonix VM
| -> Whonix Host
|
|-> Unistation Baremetal*
Is to become its own separate thing with clearnet access and selective anonymity profiles (potentially VPN/I2P access thrown into the mix) on baremetal, using lightweight app sandboxing to do its thing.
If Unistation too complex with diminishing returns, go for a hardened vanilla baremetal Kicksecure and forget about the whole anonymity part.
This is because the Whonix brand stands for “the all Tor operating system”. No exceptions. No IFs. That brand must not be damaged / confused / diluted.
One method you could do it (using whonix inside a debian based OS) is to install torghost hxxps://github .com/SusmithKrishnan/torghost in the whonix-host,and then start whonix gateway, but in my case sometimes I have some problems.
Debian based OS (using torghost, so all is torrified and using TCP) -> whonix gateway (connect directly to torghost) -> whonix workstations or other vm connected to the whonix gateway.
I run torghost because at the end is my main host OS, and so I still use mozilla firefox. But the problem is like Patrick says, is to rover tor.
So we should be look for another solution in which main host connection is already torrified, and gateway connection is torrfied but in separate mode, not in tor over tor.
Also I do not if using torghost in main host OS, and then using tor browser is still tor over tor (I suppose that yes), or if using tor inside whonix would be tor over tor.
We already have an idea of how this should be implemented, but need time to do it. The address ranges of Virtual networks would be excluded in host iptables rules from redirection to Tor.
I think that there should be an exception, maybe just for using Kicksecure VMs without Tor, there could be some kind of warning with this.
For most people to be able to use this as their daily driver, they need some way to have non-tor vm as not all activites can be done over tor due to restrictions and in some cases tor might not be helpful. Unfortunately the digital infrastructure isn’t here for most people to use only tor all the time.
I’m not sure if Kicksecure VM templates are planned to be included in Whonix host, but it would be at least a good option during installation with a clear warning, or at least something that can be ‘apt-get’ installed from the whonix repo.
A combination of Whonix & Kicksecure VMs is in my opinion something that really makes daily usage (and adoption) a lot more practical.
if a user has Kicksecure on their Whonix Host, it should be able to use the clearnet with our planned changes to iptables rules. The Kicksecure template points to the “default” virtual network.