onion_knight via Whonix Forum:
Just to keep focus, I thought it might be useful to sum up what’s being discussed here. Probably some redundant stuff, but it’s easy to lose focus when there are so many parameters involved. Please let me know if I forgot something.
So we are discussing whether the Whonix Host/Desktop currently in development (temporary name, see here for more details about the project: Whonix-Host Operating System (OS) ISO - #79 by Patrick) should be shipped with default Whonix/Tor settings or not.
As a reminder, the Whonix Host/Dekstop project currently aims at providing the following features:
A fully functioning XFCE Desktop based on Hardened Debian (also temporary name), basically a Debian stable derivative with various enhanced security settings (see Kicksecure - Security Focused Linux Distribution based on Debian - In Development - Feedback Wanted!)
Shipped as a live bootable BIOS/UEFI ISO file with preconfigured Whonix-Gateway/Workstation VMs running on KVm for amnesic use and the Calamares Installer to install the whole system on hardware (see Whonix Desktop Installer with Calamares - field report)
Yes.
As far as I understand, this seems technically rather challenging as:
- The list of installed packages will unmistakably reveal he is a Whonix user
- Fetching Whonix repositories when updating will unmistakably reveal he is a Whonix user
- Disabling updates for Whonix packages is bad for security
Indeed.
- If the only thing which immediately identifies the user as a Whonix (not only Linux/Debian) user is the Whonix repositories/list of installed packages, then it’s just a question of not updating the machine on an untrusted network, right?
So this eventually boils down to the user choice and wisdom, i.e. a simple warning could be added in the documentation/displayed when running apt update(warning: updating your system may reveal that you are a Whonix user, or something like that), then no need to change the code or disabling Whonix packages…
There could be other things we are not aware of. For example:
[1] The specific package selection by Whonix may result in a specific
set of (font) packages which pulls packages different from a standard
Debian installation. These might then leave a specific network
fingerprint (though website fingerprinting [something that happens at
ISP or Tor exit relay level]).
[2] One package that influences how traffic is shaped is openssl. There
are a ton of other libraries that influence things. Whonix-Host would be
released at a specific time (impossible to sync this with Debian
exactly), therefore a new installation would have very specific package
versions installed. A selection of package versions unique to that
release version of Whonix. The specific selection of packages with their
versions might make the traffic look unique.
- Regarding Tor services and connections, I still believe Tor should not be enabled by default, but only upon user’s consent, for instance on first boot with Anon Connection Wizard - Whonix as was suggested above. It can always be activated later.
Yes.
In such a configuration, unnecessary Whonix services that may run automatically and connect to Tor (thinking about sdwdate, Whonix Check, other stuff?) would be deactivated if the user opts out.
sdwdate would wait indefinite and do nothing. If Tor doesn’t connect,
any applications configured to use Tor cannot connect. whonixcheck on
Whonix-Host probably doesn’t autorun and run torified (or any)
connections, perhaps update check.
What do you think?
Sounds ok in theory but looks still beyond practicality due to [1] and [2].
My conclusion:
- Hiding Whonix from ISP level observer seems futile.
- Hiding Tor from ISP level observer seems futile too.
- The Tor Project researched and developed Tor, an anonymizer. There is
research and implementation for that. Censorship circumvention was an
afterthought. - Hiding a Linux distribution or Tor from ISP level observers is neither
researched, nor implemented anywhere. - Censorship circumvention is something that a small fraction users is
capable of on a trial and error basis “make it work somehow”.
The following quote totally destroys it.
Using private and obfuscated bridges alone does not provide strong
guarantees of hiding Tor use from the ISP. As Jacob Appelbaum has noted:
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.
https://mailman.boum.org/pipermail/tails-dev/2013-April/002950.html
http://www.webcitation.org/6G67ltL45
I hereby officially declare hiding Tor to be dead.
Hide Tor use from the Internet Service Provider needs to
be updated with the information gathered here.
Hiding might be something that someone could try on a best effort basis
but nothing to be relied on. It might even work for some users for some
amount of time. Such as these visiting WiFi hotspots which are somehow
magically not surveilled, then move on, however beyond practicality
since endless data retention, with retroactive analysis and retroactive
policing is a threat model most users (such as those often using from
personal name registered ISP) are vulnerable to.