[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Hiding Tor / Whonix is difficult beyond practicality?

As per these two subjects:

Related:

Let’s say the Whonix-Host would be fully torified and the user using private (non-published), obfuscated bridges. That would still looks suspicious to an ISP since it lacks the usual Windows desktop operating system update and other phone home traffic. Would still be an “extremist” non-mainstream operating system user.

1 Like

This would be interesting but it would be difficult to determine exactly what would identify a Whonix/Tor user.

A lot of network traffic going to just one IP address may also be suspicious but stream isolation will solve this for the most part.

Should it hide that the user is running Linux too? That sounds a lot more difficult.

1 Like

I’ve made a quick draft of some things and adversary could do.

Identify a Whonix/Tor user even with bridges:

  1. Network hardening - security misc - not necessarily linked to Whonix but puts user into another subset.
  2. List of installed packages - torifying apt would help this.
  3. Adversary can send packages to user’s machine. Whonix firewall will drop invalid packages. Analyse dropped vs non-dropped packages.
  4. Lots of traffic going to one IP - suspicious - stream isolation helps.
  5. Lots of traffic going to one IP daily - may be a hint to guard nodes.
  6. Using Linux - puts user into another subset.

Identify Linux user:

  1. TCP/IP fingerprint.
  2. No Windows phone home traffic.

Solution:

Boot options/build options to change settings.

  1. Disable network hardening.
  2. Make sure apt is torified - Whonix Host needs this - Whonix VMs torify by default with stream isolation.
  3. Mix up guard nodes. Don’t connect to same one for long periods of time. Maybe even switch during a session.
  4. Add random traffic at boot to make it look like Windows. Maybe even ping Microsoft’s domains.
  5. Tor should prevent site from seeing TCP/IP fingerprint. They should see the exit node’s fingerprint. If not using Tor then a kernel patch is needed https://nmap.org/misc/defeat-nmap-osdetect.html.
  6. Maybe disable Whonix firewall or prevent it from dropping packages.
1 Like

When using a bridge, the entry to Tor is the same for all streams.

This is actually considered less secure due to a higher probability to encounter a malicious guard when performing frequent rotation.

If the attempt to mask the OS isn’t perfect (contradicts other fingerprinting tools), does it make the user even more interesting?

I am not sure Whonix users will appreciate any contact with Microsoft (or with anyone else for that matter unless absolutely necessary).

Tor project gave up on this (used to display a Windows-like fingerprint in the past), Tails gave up on that from the display angle (used to have a win7-like desktop). I don’t think those attempts are feasible. If we want to look exactly like a common, non-Tor, Windows user we will probably need to be just that.

1 Like

Yes but this isn’t about max security. It’s about hiding Tor at all costs.

It could probably be passed off as a bug or misconfigured network.

For some people it could be absolutely necessary. This is for if people would face prison or other big problems for using Tor/Whonix.

They gave up on preventing an adversary who’s website they’re on or who has access to their machine on finding out the OS. What this would do is prevent a network level adversary from finding out the OS like an ISP or government agency.

1 Like
  • One Tor for Whonix Desktop is not desirable nor practical.

    • Not desirable because of security. Sharing the same Tor instance
      across multiple trust levels is dangerous and can leak data about some other activity.
    • It is sometimes needed to spin up more than One GW for secure Tor
      usage when doing multiple activities and wanting to keep guard risk down as mentioned by Tariq.
  • We DO want some traffic on Hardened Debian (host or VM) to go through Tor like sdwdate and apt, but not all (for example browser in Hardened Deb VM for captive portal auth). Tor is needed for enhanced security in these usecases.

  • We DO want ACW to choose how Tor connects on Hardened Debian.

  • We DO want to control what traffic leaves a non-Torrified host.
    OpenSnitch is an outgoing app traffic firewall and they release .debs,
    but it is not included in Debian. Chris Lamb (former leader) opened a
    packaging request for it: https://bugs.debian.org/909567.

3 Likes

A malicious node means it may very well be an adversary from which hiding Tor is attempted. so, fail on both counts of security and Tor-hiding. Plus, I don’t think anyone is interested to compromise on security.

Wishful thinking. An advanced adversary will test how Whonix Host behaves, if not actually be aware of the features implemented. Whonix is no secret.

Pinging MS as a major factor that decides prison time is very unlikely. A simplistic disguise with no basis to assume it will work. There’s a lot of traffic generated by Windows, the only way to fully pose as windows convincingly is use Windows.

I understand the motivation, but as I mentioned above, trivial steps such as pinging or providing a false response will not do the job but may very well do the opposite.

2 Likes

Agreed 100%.

Great if that could be optional.

Looks very interesting.

2 Likes

madaidan via Whonix Forum:

I’ve made a quick draft of some things and adversary could do.

That’s a nice overview. Let’s please collaboratively edit your post
above and then at some point copy it over to the wiki. Would make a nice
addition.

  1. Lots of traffic going to one IP - suspicious - stream isolation helps.

Stream isolation does not influence entry guards / bridges. That only
changes what Tor exit relays can correlate to the same pseudonym.

  1. Lots of traffic going to one IP daily - may be a hint to guard nodes.

Yes. To one / a few (depending on entry guards vs how many bridges).

Identify Linux user:

  1. TCP/IP fingerprint.://forums.whonix.org/t/hiding-tor-whonix-is-difficult-beyond-practicality/7408/3) or reply to this email to respond.
  2. No Windows phone home traffic.

Solution:

Boot options/build options to change settings.

Patches welcome.

  1. Mix up guard nodes. Don’t connect to same one for long periods of time. Maybe even switch during a session.

That would lead us into “Whonix modified Tor” territory, Whonix project
trying to be more clever than The Tor Project as far as the Tor routing
algorithm is concerned.

https://www.whonix.org/wiki/FAQ#Does_Whonix_.E2.84.A2_Modify_Tor.3F

This being opt-in (or separate build), patches might be acceptable.

  1. Add random traffic at boot to make it look like Windows. Maybe even ping Microsoft’s domains.

I doubt that would go far. To look like Windows traffic the only
reliable way is most likely using real Windows to generate that traffic.

1 Like

I unfortunately agree with sheep. Faking having a Windows network
fingerprint and having an ISP level watcher believe it infeasible.

That’s like a wholly different project. We don’t have anyone before us
attempting to make a Linux desktop computer looks like a Windows desktop
computer from network fingerprint perspective. We’d have to analyze and
compare the traffic. Sounds like a good task for a research paper.

I wouldn’t be surprised if researchers even where to find ways to
determine a Windows running from a VM (and nothing else on host) vs a
Windows running on a host looking different from a network fingerprint
perspective.

madaidan via Whonix Forum:

It could probably be passed off as a bug or misconfigured network.

That sound quite shaky.

We could configure some OS fingerprint modifications and then take the
standpoint “we believe it works until someone reports evidence that it
does not” but that would be probably “operation success, patient dead”
style.

2 Likes

ACW could be used to opt-in use of Tor.

Those not wanting to use Tor however would have to edit apt sources lists and remove the tor+ to be able to upgrade through clearnet.

Does that sound great and/or optional enough?

2 Likes

I don’t know how they do it, but Beef project does give an indication whether the hooked browser is being ran from a VM or not.

Looks good in my opinion.

I was under the impression we recently removed the tor sources anyway due to low reliability?

1 Like
1 Like

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) 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:

  1. A fully functioning XFCE Desktop based on Hardened Debian (also temporary name), basically a Debian stable derivative with various enhanced security settings (see Hardened Debian - Security Focused Linux Distribution based on Debian - In Development - Feedback Wanted!)

  2. 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)

The reasoning behind removing all Tor/Whonix-related stuff on the Whonix Host/Dekstop is that the end user may want to benefit from the various security enhancements we ship with this derivative without actually starting up Tor services/being identified as a Whonix user, which in certain instances could even hurt him.

If he wants to use Tor and Whonix, he would instead use the preconfigured Whonix VM that work out of the box, both from the live iso and from the installed system.

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

  • Some security settings related to the Hardened Debian project are probably another fingerprinting measure tying the machine to Whonix (but also probably harder to detect)

My proposal:

Why don’t we try to find some kind of reasonable middle ground:

  • Let’s not try to be “smarter than Tor” to quote @Patrick, hiding the fact that we are a Linux/Debian derivative, faking Windows network pattern is probably overkill right now

  • 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…

  • 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 https://www.whonix.org/wiki/Anon_Connection_Wizard as was suggested above. It can always be activated later. In such a configuration, unnecessary Whonix services that may run automatically and connect to Tor (thinking about swdate, Whonix Check, other stuff?) would be deactivated if the user opts out.

What do you think?

1 Like

A post was split to a new topic: upload Whonix packages to packages.debian.org

sheep via Whonix Forum:

I was under the impression we recently removed the tor sources anyway due to low reliability?

onions are different from tor+http(s) (which is torified over clearnet)

1 Like

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) 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:

  1. A fully functioning XFCE Desktop based on Hardened Debian (also temporary name), basically a Debian stable derivative with various enhanced security settings (see Hardened Debian - Security Focused Linux Distribution based on Debian - In Development - Feedback Wanted!)

  2. 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 https://www.whonix.org/wiki/Anon_Connection_Wizard 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.

https://www.whonix.org/wiki/Hide_Tor_and_Whonix_from_your_ISP 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.

3 Likes

Thanks for the discussion and the opportunity to confront ideas!

Just so we can move on and progress with the project, would we agree that we have consensus on:

  • not removing Whonix specific packages on the Whonix-Host install (default settings, nothing to do)
  • not removing Whonix specific repositories on the Whonix-Host install (default settings, nothing to do)
  • giving the user the choice whether he wants to enable Tor AND to torify apt commands on the Whonix-Host (needs to enable Anon_Connection_Wizard on first boot - this may be added at a later stage as an additional functionality)
1 Like

Perfect.

Great! Then I will try a new Host build and report back on the state of the project.

2 Likes