I am experimenting with Whonix 14 Gateway and it works very well, a huge step forward compared to 13.
I am using it as a typical desktop system (without using of workstation) and understand the risks, but this setup is enough for me(I was unable to break the system ever flushing the iptables). Are there any hidden disadvantages?
Is it possible to encrypt the whole system with LUKS? I have read the previous discussions here and the solution with “cryptsetup-reencrypt” seems to be ok especially compared to not having encryption at all.
To start, if anonymity is important you should Not Under any Circumstances use Whonix-Gateway as a Workstation. If Whonix-Gateway is ever compromised its game over.
Hidden disadvantages from doing what? flush iptables?
Yes, you can encrypt your host with FDE.
It is possible to encrypt your host if it has not been already. It is considered experimental and there are risks that all data could be lost. IIRC this requires you have enough RAM to store all data on your file system. RAM is where data is stored during the encryption process. Be sure to create backups before you do anything.
This would depend on the operating system you are using. If using Windows its a no-go on LUKS. If using Linux you should find much information on encrypting host.
If the Whonix-Gateway VM is ever compromised, the attacker can discover: the user’s identity (public IP address); all destinations visited; and the entirety of clear-text and onion service communication over Tor.
Before installing any extra packages on the Whonix-Gateway, first consult the developers to check whether that is necessary and wise.
The traditional approach with one VM is more convenient to me, despite the fact that it has its own disadvantages. It is especially easier to transfer such VM to less literate users or workers as a portable solution. They may not always understand how to deal with two VMs or just forget to turn the gateway or workstation off. In addition to lack of gateway+workstation encryption I think the risks are higher in such case compared to possible attacks to one VM solution. This is my guess.
The host encryption is a must anyway, but I mean additional guest encryption. I was trying to “cryptsetup-reencrypt” the Gateway but since partition size is 100gb the cryptsetup intended to crypt the whole dynamic partition, inflating it from 4 GB to 100.
Hidden disadvantages from using Gateway as a Workstation, like Tails. The only weak point I see is browser.
That’s false. If you want a simple one machine for all purposes then use Tails whose settings are configured to protect you in that case otherwise you are risking leaks using GW for purposes it wasn’t designed to do.
Tails’ approach is amnestic, which is not fully suitable to everyday work, I find whonix more appropriate, and most importantly it works.
Let’s imagine the following situation. The lazy user goes in a country where using tor is not fully welcomed. The user has an encrypted one VM in his cloud storage. He downloads it and the system is ready to work without further customization. After the work is finished and the guest VM has been shot down no one can guess that it was whonix but not innocuous debian, even with physical access to the host system thereafter. Host system risks are not taken into account.
In the current situation if the user forgets to turn the workstation off, it can lead to revealing the whole workstation’s data. Forgetting to turn the gateway off is more innocuous and at worst it can attract unnecessary attention but not revealing the sensitive information.
But if you now use the gateway as workstation in your setup then you have everything in the gateway. If you then forget to shutdown the gateway you can also reveal sensitive data + you significantly increased your risk for deanonymization.
This is normal. The easiest way around would be to build a custom VM with a smaller size. This can be changed in the build script.
I’m not quite sure how your cloud encrypted VM setup should work. If it is just supposed to be a Whonix VM with full disk encryption then this won’t help you against detecting Whonix since the GRUB bootlader will always remain unencrypted and show something with Whonix in the name. So you would need to change that, too. Or put the VM in an encrypted container, but then you also have to care about not leaking metadata like VM names in log and config files. I’m also not sure if using cryptsetup-reencrypt directly would help. The current disk setup has everything in one partition. A normal FDE setup has in most cases two partitions with /boot being unencrypted. You maybe could use GRUB to decrypt the whole disk including /boot. Anyways, FDE on the host will solve most if not all of your problems and be the easiest to setup.
Encrypting the disk hides disk contents but it can’t authenticate the whole ova image. I.e. it cannot deliver integrity protection. For that you would still need gpg or similar.
What’s missing in their persistent volume options?
It works when it’s used as it’s supposed to be used. You don’t trust your lazy users to turn the VM off but you trust them not to get phished or d/l malware by mistake?
True. Also VirtualBox as well as libvirt can be used to encrypt complete images including GRUB and /boot but the size would probably also increase to the maximum disk size.
True. Also VirtualBox as well as libvirt can be used to encrypt complete images including GRUB and /boot but the size would probably also increase to the maximum disk size.
VirtualBox: Would that be secure? Cover all the VM ova? Or would parts
of the VM (like settings files) still be unencrypted, therefore target
for MITM?
Even if VirtualBox had full ova encryption… Does it? Is it securely
implemented?
Just trying to ask the right questions. Not expecting anyone knows right
away.
The usecase for this is mostly sharing complete VM images with sensitive data. Those features were likely not designed for hiding the use of a certain VM. For Virtualbox it only encrypts the disk. FDE on the host would certainly be the most secure option.
In case you have to choose yes, FDE on the host is the best solution, but it doesn’t eliminate the need for specific encryption. It’s like having all your passwords in a plaintext file on a desktop because you have FDE. Whonix workstation and possible future oneVM definitely need a mode to encrypt the system.
It’s closed source, so no exact answer can be given. It’s definitely better than nothing, but it encrypts just final vm’s hard drive, without settings, logs or ova images.
By the way another point to the benefits of oneVM is possibility to run using Vmware Player which allows to turn the VM logs off.