anon-ws-disable-stacked-tor

Whonix ®

Download

Windows Linux Mac VirtualBox KVM Qubes USB ISO (coming soon) More options Source Code

About

Overview Features Whonix vs VPNs Why Open Source? Project Activities Contributors Mission & Vision

Docs

Documentation FAQ Troubleshooting

Community

Forums Contribute

Support

Self Support First Policy Search Engines, Docs and AI Support (Limited) Reporting Bugs Contact (Restricted)

Tools Upload file Special pages Recent changes Print Version Page meta What links here Related changes Page information

Page Read Edit History Move Protection Unwatch Watch Delete Purge

User Preferences Watchlist Contributions Logout Create account Login

Donate

Preventing Tor over Tor for Tor Browser, TorChat and others.

Introduction

There is only 1 Tor daemon (long-running process, program) running on Whonix-Gateway^™.

When starting Tor Browser in Whonix-Workstation^™, the integrated Tor, which comes with the Tor Browser Bundle, will not be started.

Therefore, there are no duplicate Tor daemons running in Whonix by default, except in the case of some corner cases.

Why?

See Prevent Tor over Tor Scenarios.

Rationale on implementation details, SocksSocket vs TCP, environment variables vs settings file

Implementation

Environmental Variable Adjustments

• /etc/X11/Xsession.d/20torbrowser
• /usr/libexec/anon-ws-disable-stacked-tor/torbrowser.sh

Providing Virtual Tor Package

Implemented in anon-ws-disable-stacked-tor, debian/control. The package uses the Provides: tor field, which should avoid any conflicts in case upstream releases a higher version of Tor. This won't work for packages that depend on an explicit version of Tor (such as TorChat). This is non-ideal since, for example, the torchat package will install Tor. However, this is still acceptable because of the following additional implementations.

Tor Binary Replacement

Tor's binary was replaced (dpkg-diverted using config-package-dev) with dummy executables, so even if the real tor package gets installed, it won't be automatically started.

• https://github.com/Whonix/anon-ws-disable-stacked-tor/blob/master/usr/bin/tor.anondist
• https://github.com/Whonix/anon-ws-disable-stacked-tor/blob/master/usr/sbin/tor.anondist

systemd-socket-proxyd Listening Port Redirection

Listening using systemd-socket-proxyd on the following listening ports:

• Tor's default listening ports. I.e.:
  • system Tor's SocksPorts 127.0.0.1:9050, 127.0.0.1:9051, and
  • Tor Browser's SocksPorts 127.0.0.1:9150, 127.0.0.1:9051,
  • Tor Messenger's SocksPort 127.0.0.1:9152

These are redirected to the gateway.

Also applies to ControlPorts:

• Tor's 9051
• Tor Browser's 9151

These are redirected to Tor (actually control port filter proxy (onion-grater) on the gateway).

• and others, see full list.
• These listening ports are forwarded to Whonix-Gateway.
• This prevents the default Tor Browser, Tor Messenger, and/or Tor package by The Tor Project from opening these default ports, which will result in Tor failing to open its listening port and therefore exiting, thus preventing Tor over Tor.

TODO: describe

• systemd socket activation
• https://web.archive.org/web/20221128013446/https://phabricator.whonix.org/T357

Unix Domain Socket File Redirection

Since Tor Browser, OnionShare (screenshot) among more and more other applications require SocksSocket , anon-ws-disable-stacked-tor is also providing:

• Tor Control Unix Domain Socket file: /var/run/tor/control, which is redirected to Control Port Filter Proxy on Whonix-Gateway.
• Tor Control Auth Cookie: a functional /var/run/tor/control.authcookie that works with onion-grater (Control Port Filter Proxy).
• Tor Socks Unix Domain Socket file: /var/run/tor/socks that is redirected to Whonix-Gateway Tor port 9050
  • full list.

Tor State File Creation

All required state files that Tor would normally create in /var/run/tor and /var/lib/tor are being created by /usr/lib/anon-ws-disable-stacked-tor/state-files.

bindp

TODO: describe

• bindp
• https://forums.whonix.org/t/find-way-to-have-tor-ephermal-hidden-service-using-applications-in-whonix-workstation-bind-on-all-interfaces/18846

socat

There are no socat redirections by default in Whonix.

Advanced setups such as Monero CLI Wallet/Daemon Isolation with Qubes-Whonix^™ are using things like EXEC. From that example:

socat TCP-LISTEN:18081,fork,bind=127.0.0.1 EXEC:"qrexec-client-vm monerod-ws user.monerod"

systemd-socket-proxyd does not support EXEC, hence socat is useful here.

Limitations

Not all arbitrary applications with their own Tor integration have their internal Tor disabled.

• Applications installed from Debian package sources and manually installed applications have the "lowest risk" of Tor over Tor / "highest chance" of anon-ws-disable-stacked-tor being functional. If the application honors the common environment variable TOR_SKIP_LAUNCH=1, then there should be no issue.
• Applications shipped through Flatpak: There is currently no technical approach for how anon-ws-disable-stacked-tor could disable an application's internal Tor in the Flatpak chroot. This matters, for example, for OnionShare if installed from Flatpak. See Dev/OnionShare.
• Applications shipped through AppImages: same as above.

Debugging

Run:

echo "$TOR_SOCKS_IPC_PATH"

Should show the following:

/var/run/anon-ws-disable-stacked-tor/127.0.0.1_9150.sock

---

Run:

echo "$TOR_CONTROL_IPC_PATH"

Should show the following:

/var/run/anon-ws-disable-stacked-tor/127.0.0.1_9151.sock

Also, please run:

UWT_DEV_PASSTHROUGH=1 curl 127.0.0.1:9150

Should show the following:

<html>
<head>
<title>Tor is not an HTTP Proxy</title>
</head>
<body>
<h1>Tor is not an HTTP Proxy</h1>
<p>
It appears you have configured your web browser to use Tor as an HTTP proxy.
This is not correct: Tor is a SOCKS proxy, not an HTTP proxy.
Please configure your client accordingly.
</p>
<p>
See <a href="https://www.torproject.org/documentation.html">https://www.torproject.org/documentation.html</a> for more information.
<!-- Plus this comment, to make the body response more than 512 bytes, so      IE will be willing to display it. Comment comment comment comment      comment comment comment comment comment comment comment comment.-->
</p>
</body>
</html>

Run a similar command:

echo GET | socat - UNIX-CONNECT:/var/run/anon-ws-disable-stacked-tor/127.0.0.1_9150.sock

Should show the same as above.

---

Next one to try:

UWT_DEV_PASSTHROUGH=1 curl 127.0.0.1:9151

Should show the following:

510 Request filtered
...

Run a similar command:

echo GET | socat - UNIX-CONNECT:/var/run/anon-ws-disable-stacked-tor/127.0.0.1_9151.sock

Should show:

510 Request filtered

Debugging with curl

Trying to use curl rather than curl.anondist-orig is a common mistake when debugging Whonix network issues.

curl is a symlink to curl.anondist-orig. In turn, this symlinks to uwtwrapper, which runs curl under torsocks. torsocks then forces Tor to run on localhost for stream isolation.

• The uwt stream isolation wrapper must be circumvented or disabled.
• The command must be run under the user clearnet.

In Whonix-Gateway or sys-whonix Qubes-Whonix:

1. Switch to user clearnet:

sudo -su clearnet

2. Circumvent the uwt stream isolation wrapper by appending .anondist-orig to curl:

curl.anondist-orig <your_url>

In the following examples, the exec calls from the command output show the difference between running curl with the uwtwrapper both enabled and disabled.

Example 1

curl is run with the uwtwrapper enabled:

uwtwrapper_verbose=1 curl <your_url>

This results in the following exec calls. Only the latest (most recent) call matters, which shows torsocks is prepended before running curl:

exec torsocks /usr/lib/uwtexec something <your_url>
exec -a /usr/bin/curl /usr/bin/curl.anondist-orig <your_url>

Example 2

curl is run with the uwtwrapper disabled:

uwtwrapper_verbose=1 UWT_DEV_PASSTHROUGH=1 curl <your_url>

This command results in the following exec calls, which show torsocks does not get prepended before curl. Since curl does not run under torsocks, local connections are not hindered, and there is no stream isolation:

exec /usr/lib/uwtexec <your_url>
exec -a /usr/bin/curl /usr/bin/curl.anondist-orig <your_url>

The output from the previous commands establishes the following:

• /usr/bin/curl is symbolically linked to /usr/bin/curl.anondist-orig. This demonstrates /usr/bin/curl.anondist-orig is the actual (real) curl binary.
• When /usr/bin/curl.anondist-orig is run with the uwtwrapper disabled, all uwt logic is circumvented.

Users can either circumvent the uwt stream isolation wrapper or disable it either permanently or temporarily.

Links:

• Stream Isolation
• Stream Isolation/Disable Easy

Application Developers

• Whonix friendly applications best practices
• Tor friendly applications best practices

See Also

• Redirect Whonix-Workstation Ports or Unix Domain Socket Files to Whonix-Gateway

Footnotes

Whonix The most watertight privacy operating system in the world.

Dark mode

Follow us on social media

Supported by Power Up Privacy

Whonix is proudly supported until 2025 by Power Up Privacy, a privacy advocacy group that seeks to supercharge privacy projects with resources so they can complete their mission of making our world a better place. (Strictly subject to our sponsorship policy.)

At Whonix we value freedom and trust, supporting Open Source and Freedom Software

By using this website, you acknowledge you have read, understood, and agree to be bound by these agreements: Terms of Service, Privacy Policy, Cookie Policy, E-Sign Consent, DMCA, Imprint 2012- 2024 ENCRYPTED SUPPORT LP

Your support makes
all the difference!

We believe security software like Whonix needs to remain open source and independent. Would you help sustain and grow the project? Learn more about our 12 year success story and maybe DONATE!