Hiding Tor is difficult beyond practicality?

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

Frequently Asked Questions - Whonix FAQ

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

  1. 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!)

  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 Anon Connection Wizard - Whonix 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 (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:

  1. 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!)

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

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

i find this quite lazy, a 6-year-old quote from Appelbaum is your proof that pluggable transports are useless :face_with_monocle:

obviously there exists a wide spectrum of adversaries and adversary capacities, some can block some pluggable transports, some can’t. the idea is to make that work as difficult as possible for them. a nice overview of the different pluggable transport approaches is here:

pluggabletransports.info/transports

it continues to be an active field of research and implementation, you can follow along at that website.

in addition, from the perspective of hiding Whonix use (as currently distinct from Debian, Tails, etc), as has been mentioned in this thread, you could continue to decompose Whonix into Debian-based packages, having all Whonix packages be maintained within Debian repos.

also helpful towards reducing network fingerprinting of Whonix users were the previous efforts to have a shared Tor Browser user profile across Whonix, Tails, Tor Browser.

I see the quote from appelbaum among several posts arguing against spending resources on hiding Tor. Not sure how you came to this conclusion.

Indeed.

mfc via Whonix Forum:

i find this quite lazy, a 6-year-old quote from Appelbaum is your proof that pluggable transports are useless :face_with_monocle:

Other reasons where states here too.

obviously there exists a wide spectrum of adversaries and adversary capacities, some can block some pluggable transports, some can’t. the idea is to make that work as difficult as possible for them. a nice overview of the different pluggable transport approaches is here:

Blocking vs non-blocking is besides the point since that is
circumvention. “circumvention” meaning “just make it work, it’s ok if
someone finds out I used Tor later”. That use case is much easier to
keep supporting.

This is about hiding Tor, i.e. “make it work and make sure no one will
ever find out I used Tor”. Due to very realistic assumptions such as
extended logging of traffic, progress in pluggable transport detection
and retroactive policing it is a very bad idea to try to circumvent Tor
which may even be possible at the time when later (lets say weeks,
months or years) detection is still a personal risk.

in addition, from the perspective of hiding Whonix use (as currently distinct from Debian, Tails, etc), as has been mentioned in this thread, you could continue to decompose Whonix into Debian-based packages,

All of Whonix is available as Debian packages for years.

List of packages: Whonix ¡ GitHub

“sudo apt install whonix” is possible and done so by third parties in
the wild. References:

having all Whonix packages be maintained within Debian repos.

That would be very nice for other reasons but unfortunately very
unrealistic. Few reasons given here before:

A Debian Maintainer who stepped down explaining the challenges /
impossibilities changing Debian in human life spawns:

But even if we had that, when even readers of linuxjournal are already
called extremists in the West with relatively many Linux users…

https://www.linuxjournal.com/content/nsa-linux-journal-extremist-forum-and-its-readers-get-flagged-extra-surveillance

…you can imagine how much users of Linux stand out in countries where
use of Tor is not only blocked but deemed dangerous.

Solution? [1] Debian or any Linux going mainstream on the desktop and
[2] producing lots of Tor traffic by default. I see neither [1] nor [2]
coming.

also helpful towards reducing network fingerprinting of Whonix users were the previous efforts to have a shared Tor Browser user profile across Whonix, Tails, Tor Browser.

Whonix uses the same Tor Browser profile as Tor Browser, in other words
unmodified. What Tails is doing is up to Tails. They’ve been criticized
for their custom profile by others. Arguments were made. I don’t think I
could talk them out of it.

However, Tor Browser fingerprint matters at the end of the connection,
i.e. at the destination server. ISPs won’t be able to differentiate
Whonix, Tails, Tor Browser at the ISP level (unless something is very
wrong).

1 Like

I have read on this site that “hiding TOR/whonix is difficult beyond practicality”, Is that really true? aren’t pluggable transports meant to hide the fact that you are using TOR in countries where it is illegal? I even remember something about some pluggable transports that disguises your traffic as a"normal" traffic to some website.
Can the government/ISP see all the TOR users all the time?

Edit: Hi underdog, Welcome to the Whonix Community!

Please use exitsting treads of one is available. @0brand moderator. Forum Best Practices.

They provide circumvention. Not hiding. Circumvention might work. Hiding is what people like to interpret into it. Social communication issue.

Again, circumvention, not hiding.

Even if they don’t - it’s likely that all traffic is being logged permanently. Even if not detectable now, traffic can be reanalyzed again and again and a later more sophisticated analyser might detect it later on. Hiding failed.

Page Hide Tor use from the Internet Service Provider contains technical reasoning, quotes, links. Verifiable.

Try to find a technical argument, developer of a pluggable transport, or other expert who’s pressed on the circumvention vs hiding question, who states it is for hiding.

It’s not about truth or certainty but with the information available this was the conclusion.