Stream Isolation

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

Free Reporting Bugs Contact

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

• short stream isolation summary
• all information below

Prevent Identity Correlation through Circuit Sharing by using Tor Stream Isolation.

Old illustrative Whonix stream isolation image.

Introduction

Essentials

If the internet is used normally, without Tor, a proxy or VPN, there is not really a widespread term for this. Could be coined "connecting over clearnet".

When using Tor without Whonix such as when using the Tor Browser Bundle on a host operating system such as Windows or Debian, only the Tor Browser Bundle connect over Tor. All other applications are still using clearnet.

In case of Whonix: All traffic originating from Whonix-Workstation^™ and Whonix-Gateway^™ is routed over Tor.

Transparent Proxy

This chapter explains what a Transparent Proxy is. It is required to know in order to understand the following chapters.

• Transparent proxying means, simplified and unspecific to Whonix:

  An application can connect without additional configuration required.

• Use Firefox on host operating system without Tor or any proxy/VPN without Whonix involved: Not sure that should be called that "transparent proxying". Should probably not call it that way to avoid confusion. In that case probably the home router is doing "transparent proxying". A proxy that is transparent. It does stuff for the user/program without the user necessarily having to know anything about it.
• Using Tor Browser on the host without Whonix involved: This is an example for "no transparent proxying available".
• There are also other types of transparent proxies such as content filtering, virus scanning, and what not.
• More complex specific to Whonix:

  An application can use TCP/DNS [UDP blocked] over Tor (user -> Tor -> destination) without additional configuration required.

Whonix has feature transparent proxying enabled by default. transparent proxying is a feature that most users want. Not enabling transparent proxying by default would be confusing for most users.

In other words, Whonix-Gateway by default can be used as a Tor Transparent Proxy. Connections from Whonix-Workstation^™ to Whonix-Gateway are transparently proxied through Tor.

For example if using Telegram in Whonix: Uses transparent proxying because it is not pre-configured by default to use Tor proxy settings.

Identity Correlation through Tor Circuit Sharing

If the user installs custom applications and omits to explicitly take precaution against identity correlation through Tor circuit sharing, the user is risking that different activities, let's say web (Chromium or similar) or IRC (mIRC or similar) go through the same Tor circuit and Tor exit relay. Even though the user would still be anonymous, i.e. the Tor exit relay would still not know the user's real IP/location, the Tor exit relay and their internet service provider (ISP) can easily correlate those activities by different applications to the same pseudonym.

The following graphic illustrates the difference of using Tor SocksPort's compared to using Tor's TransPort. Using a dedicated Tor SocksPort's per application results in taking different routes through the Tor network per application. Not necessarily all Tor relays (first, second, third) get replaced by Tor. Sometimes just the first, sometimes just the second, sometimes just the third, and sometimes multiple Tor relays in the Tor circuit change.

This does not necessarily result in using a different Tor Entry Guard or Tor exit relay. Therefore a different Tor circuit can likely lead to using a different Tor exit relay and IP Address, but this is not guaranteed. Related: Only Use One Online Pseudonym at the Same Time

Whonix implements protection against identity correlation through Tor circuit sharing for preinstalled applications, however, for better privacy, the user is advised to understand a bit of the technical background. Different SocksPorts, DnsPorts, or TransPorts are routed through different Tor circuits, therefore preventing identity correlation.

Whonix configures most applications that come preinstalled with Whonix to use a different SocksPort, thus no identity correlation is at risk. Whonix uses either socks proxy settings to direct various applications to different SocksPorts or uwt (more information below).

Applications configured for stream isolation (those using a SocksPort) ignore /etc/hosts file. This includes for example Tor Browser. Therefore modifications to /etc/hosts for the purpose of adblocking are futile (unless using Tor Browser Transparent Proxying).

Application not configured for stream isolation, i.e. those using transparent proxying are usually honoring /etc/hosts. Select applications might have a specific implementation to ignore it depending on the application and unspecific to Whonix.

Any other traffic (i.e. custom installed applications, misc applications, such as nslookup, go through Tor's DnsPort, and/or TransPort (can be optionally disabled, see below).

List

Related:

• Whonix Default Application Policy
• Should strict stream isolation by a requirement in Whonix's Default Application Policy?

Applications in Whonix that are either prepared or fully pre-configured to prevent identity correlation through Tor circuit sharing:

By Settings

application	pre-installed	pre-configured	stream isolation by method	port	comments
Tor Browser	Yes	Yes	socks proxy settings	9150	-
Mozilla Thunderbird	Yes	Yes	socks proxy settings	9102	-
Instant Messenger	No	No	socks proxy settings	port prepared, IP 10.152.152.10, port 9103	Chat
sdwdate	Yes	Yes	socks proxy settings	9108	Dev/TimeSync
systemcheck	Yes	Yes	socks proxy settings	9110	-
Bitcoin electrum Wallet (BTC)	Yes	No (TODO)	socks proxy settings	port prepared, IP 10.152.152.10, port 9111	-
Monero (XMR)	Yes	No (TODO)	socks proxy settings	-	-
Tor Browser Downloader by Whonix	Yes	Yes	socks proxy settings	9115	-
KDE application wide proxy settings	No	Yes	socks proxy settings	9122 no KDE applications with network activity pre-installed	-

By uwt wrapper

application	pre-installed	pre-configured	stream isolation by method	port	comments
apt-get	yes	yes	uwt wrapper	-	Update
aptitude	yes	yes	uwt wrapper	-	-
gpg	yes	yes	uwt wrapper	-	-
ssh	yes	yes	uwt wrapper	-	-
git	no	yes	uwt wrapper	-	-
wget	yes	yes	uwt wrapper	-	-
curl	yes	yes	uwt wrapper	-	-
scurl	yes	yes	uwt wrapper	-	Uses curl, therefore same as curl.

none

application	pre-installed	pre-configured	stream isolation by method	port	instructions
GNOME application wide proxy settings	no	no	none	no GNOME applications with network activity pre-installed	-
systemcheck --leak-tests	yes	no	none	See footnote.	-

Details

The required socks proxy settings are setup by various Whonix configuration packages or uwt wrappers, which are set up on Whonix-Gateway^™ and on Whonix-Workstation. uwt is a wrapper around torsocks, which is also already installed to /usr/bin/uwt.

• Example, each time you run a uwt wrapped application, i.e. simply type apt-get in console, the uwt wrapper /usr/bin/apt-get will run. It adds uwt before apt-get. For curiosity check nano /usr/bin/apt-get. Essentially, the uwt wrapper then runs /usr/bin/uwt /usr/bin/apt-get.anondist-orig. That is also the case for all other uwt wrapped applications.
• If you ever want or must run a uwt wrapped application without uwt, do not run for example apt-get in console, do run apt-get.anondist-orig. Use cases could be if you want to connect to localhost. If you know what you are doing, you should also be able to deactivate any uwt wrappers you dislike, see #Deactivate_uwt_Stream_Isolation_Wrapper.
• When running /usr/bin/apt-get.anondist-orig it directly goes through Tor's DnsPort and through Tor's TransPort and not through its own SocksPort.
• uwt looks if the command contains the words localhost or 127.0.0.1, if that is the case, uwt will not be used. The command will be run without uwt. Thus, if a localhost connection is falsely detected it will leak, but only through Tor's DnsPort and through Tor's TransPort, which should be acceptable.

Isolate by destination address: Let's assume SSH goes over port 22 and you want to connect to different SSH servers and do not want an observer to be able to correlate that activity to the same pseudonym. If the SSH servers run on different IP's isolate by destination address might help.

Isolate by destination port: This doesn't seem to be useful for anything in Whonix, applications using different protocols (and therefore different ports) are already isolated through using different SocksPorts.

Isolate by destination port doesn't really achieve anything for web browsing: tor-talk Tor's stream isolation features defaults.

For more information about stream isolation refer to the Tor manual.

• Tor stable manual
• Tor alpha manual

Tor Browser

Tor Browser has a feature Tor Browser should set SOCKS username for a request based on first party domain. Tor Browser makes use of Tor's IsolateSOCKSAuth option. Whonix does not break this feature.

Note: This wiki page stated Different tabs and websites in Tor Browser are isolated by since Tor Browser. . This was either always incorrect or Tor Browser's behavior has changed meanwhile.

Tor circuit and HTTP connection linkability

Design Goal: Tor circuits and HTTP connections from a third party in one URL bar origin MUST NOT be reused for that same third party in another URL bar origin.

Implementation Status: The isolation functionality is provided by a Torbutton component that sets the SOCKS username and password for each request. The Tor client has logic to prevent connections with different SOCKS usernames and passwords from using the same Tor circuit. Firefox has existing logic to ensure that connections with SOCKS proxies do not re-use existing HTTP Keep-Alive connections unless the proxy settings match. We extended this logic to cover SOCKS username and password authentication, providing us with HTTP Keep-Alive unlinkability. While the vast majority of web requests adheres to the circuit and connection unlinkability requirement there are still corner cases we need to treat separately or that lack a fix altogether.

upstream, The Tor Project: The Design and Implementation of the Tor Browser (DRAFT)

Tor Browser is developed by upstream, The Tor Project, which is an independent entity. For up-to-date information, refer to upstream, Tor Browser.

forum discussion: https://forums.whonix.org/t/tor-browser-new-identity-differs-from-restarting-tor-browser-in-whonix/3098/4

Onion Services

Connections to different Tor Onion Services are automatically stream isolated.

How to mitigate identity correlation

Basic Protection

If you install custom software on Whonix-Workstation, that uses the internet, and want to prevent identity correlation through Tor circuit sharing (which you should do), you have to manually configure them. This is not a Whonix specific problem. Read also Software installation on Whonix-Workstation.

A #list of applications which come pre-installed with Whonix are pre-configured to prevent identity correlation through circuit sharing.

Traffic going through TransPort by default is systemcheck when manually testing the TransPort by using systemcheck --leak-tests. If that is of concern to you,

• It can be disabled in systemcheck, see prevent polluting TransPort but that might make little sense.
• Better to avoid the test instead.

All custom installed application's TCP traffic is routed through Tor's TransPort and all their DNS requests through Tor's DnsPort. This means different activities or "identities" in different applications (say browser, IRC, email) end up being routed through the same Tor circuit, thus identity correlation is at risk.

To protect against this, you have to set up configure applications to use a dedicated Tor SocksPort. Each custom installed application has to be directed to a dedicated Tor SocksPort, for directions how to do that use the Torify HOWTO. Generally, this can be done either by configuring the application's proxy settings or by using a proxifier (socksifier) such as torsocks.

Multiple Whonix-Workstation are automatically stream isolated.

What is better, configure the application's proxy settings or using a proxifier? There can be no generalized answer as this is highly application specific. The most comprehensive documentation of this is the Torify HOWTO. Also a web search could be performed on how to torify applications.

Applications inside Whonix are already torified but by applying these instructions inside Whonix the user would go one step further, i.e. add stream isolation.

Finding up to date instructions for torification is difficult because developing instructions for torification itself is a difficult process. Someone who understands networking needs to leak test if the torification instructions are actually working. Or if there is a leak which means that portion's of the applications's traffic ignore proxy settings and/or circumvent the proxifier and is actually making external connections without using Tor. Such leaks would be much less severe in Whonix. It would only result in identity correlation through Tor circuit sharing but not in a leak of the user's real IP address to the destination.

Asking for torification instructions for specific applications at Whonix Free Support is probably futile. The Whonix is the wrong recipient for such support requests. One of the main reasons for the inception of the Whonix was that finding, developing and applying torification instructions is so difficult and one never really knows if it is 100% free of leaks. Even seriously reviewed torification instructions for one application would only apply to the very version which was being reviewed. Not to future versions of the application.

The legacy approach of torification of arbitrary applications on the host seems to been largely given up. There are very few edits to the Torify HOWTO over the years. Nowadays some application developers are providing Tor-safe by default applications, i.e. applications designed for use with Tor in mind and not as an afterthought. Examples include Tor Browser and OnionShare. Also if users are asking how to torifiy specific applications and making sure these are leak free, users are probably told "use Whonix".

Additional comments regarding the Torify HOWTO:

• Warnings about protocol related warnings you must honor. You are still better off with Whonix, as it offers best possible Protocol-Leak-Protection and Fingerprinting-Protection.
• Whonix setup provides protection against IP leaks through protocol leaks.
• If you do not correctly torify either no connections will be possible or traffic will either continue going through Tor's TransPort unless you disable transparent torification.
• If you redirect more than one application to the same SocksPort, identity correlation is at risk.
• DNS related warnings still apply, though to a lesser extent - an attack could only make correlations but still couldn't figure out your IP. To prevent that see chapter better protection.
  • Do not use a local DNS resolver, as all DNS requests would be executed by the same Tor circuit.
• Other leaks, such as applications not honoring the proxy settings / wrapper, ICMP or UDP leaks do not apply to Whonix.
• The SafeSocks setting is for rejecting unsafe variants of socks that might cause DNS leaks. The Whonix design model mitigates DNS leaks by redirecting all requests to Tor's DnsPort. Enabling this setting would give marginal benefit in this situation but would complicate debugging.

On Whonix-Gateway there are already a lot custom socks ports prepared for use with custom installed applications :

• Without IsolateDestAddr and without IsolateDestPort: SocksPort 9153 to 9159
• With IsolateDestAddr, but without IsolateDestPort: SocksPort 9160 to 9169
• Without IsolateDestAddr, but with IsolateDestPort: SocksPort: 9170 to 9179
• With IsolateDestAddr and with IsolateDestPort: SocksPort: 9180 to 9189
• If those are not enough, you can add your own.

What are IsolateDestAddr and IsolateDestPort? You can learn about them in the Tor manual. See also tor-talk mailing list: Tor's stream isolation features defaults. Usually, unless you know better, you are better off not using IsolateDestAddr or IsolateDestPort.

Generic instructions for configuring custom installed applications for stream isolation for less than 7 custom applications

1. Install custom application.
2. Configure application to use a dedicated Tor SocksPort according to Torify HOWTO by either configuring the application's proxy settings or by using a proxifier such as torsocks.
3. Start custom application.

Generic instructions for configuring custom installed applications for stream isolation using proxifier (socksifier) torsocks

1. Install custom application.
2. Open a terminal.

If you are using Qubes-Whonix^™, complete the following steps.

Qubes App Launcher (blue/grey "Q") → Whonix-Workstation™ App Qube (commonly named anon-whonix) → Xfce Terminal

If you are using a graphical Whonix with Xfce, run.

Start Menu → Xfce Terminal

3. Start custom application from command line by prepending torsocks.

torsocks application-name

Using this method, there is no need to specify any proxy IP address, port number, protocol.

Generic instructions for configuring custom installed applications for stream isolation for less than 7 custom applications using the application's proxy settings

1. Install custom application.
2. Configure application to use a dedicated Tor SocksPort according to Torify HOWTO by either configuring the application's proxy settings.
3. protocol: socks 5
4. Platform specific. Proxy IP: A) Non-Qubes-Whonix 10.152.152.10 B) Qubes-Whonix: Use the IP address returned by running the following command (NOTE: do not use the command itself): qubesdb-read /qubes-gateway
5. port: 9153 (use a different port according to list above if using multiple custom installed applications)
6. Start custom application.

Better generic instructions for this cannot be provided since this is application specific as mentioned above.

Better Protection

For best protection against identity correlation:

• Read the advice above and on Whonix-Gateway.
• Deactivate KDE / GNOME - application wide proxy settings because those proxy settings are not application specific, but rather force all KDE / GNOME applications through the same SocksPort. There no KDE / GNOME applications which use the internet preinstalled by default. However, deactivating those KDE / GNOME wide proxy settings gives finer control over stream isolation.
• Disable transparent proxying as documented below.

Best Protection

Best stream isolation is only possible if you honor the advice above and only use one application per session and always revert to a fresh image or Multiple Whonix-Workstation.

Disable Transparent Proxying

To deactivate transparent proxying apply the following instructions.

Following these steps will disable the Whonix-Gateway transparent proxying feature and transform Whonix-Gateway into an IsolatingProxy.

Note: The following instructions should be applied in Whonix-Gateway (Qubes-Whonix^™: In App Qubes sys-whonix).

1. Modify Whonix-Gateway^™ User Firewall Settings.

Note: If no changes have yet been made to Whonix Firewall Settings, then the Whonix User Firewall Settings File /usr/local/etc/whonix_firewall.d/50_user.conf appears empty (because it does not exist). This is expected.

If using Qubes-Whonix^™, complete these steps.
In Whonix-Gateway App Qube. Make sure folder /usr/local/etc/whonix_firewall.d exists.

sudo mkdir -p /usr/local/etc/whonix_firewall.d

Qubes App Launcher (blue/grey "Q") → Whonix-Gateway App Qube (commonly called sys-whonix) → Whonix User Firewall Settings

If using a graphical Whonix-Gateway, complete these steps.

Start Menu → Applications → Settings → User Firewall Settings

If using a terminal-only Whonix-Gateway, complete these steps.

In Whonix-Gateway, open the whonix_firewall configuration file in an editor.

sudoedit /usr/local/etc/whonix_firewall.d/50_user.conf

For more help, press on Expand on the right.

Note: This is for informational purposes only! Do not edit /etc/whonix_firewall.d/30_whonix_gateway_default.conf.

Note: The Whonix Global Firewall Settings File /etc/whonix_firewall.d/30_whonix_gateway_default.conf contains default settings and explanatory comments about their purpose. By default, the file is opened read-only and is not meant to be directly edited. Below, it is recommended to open the file without root rights. The file contains an explanatory comment on how to change firewall settings.

## Please use "/etc/whonix_firewall.d/50_user.conf" for your custom configuration,
## which will override the defaults found here. When {{project_name_short}} is updated, this
## file may be overwritten.

See also Whonix modular flexible .d style configuration folders.

To view the file, follow these instructions.

If using Qubes-Whonix, complete these steps.

Qubes App Launcher (blue/grey "Q") → Template: whonix-gateway-17 → Whonix Global Firewall Settings

If using a graphical Whonix-Gateway, complete these steps.

Start Menu → Applications → Settings → Global Firewall Settings

If using a terminal-only Whonix-Gateway, complete these steps.

In Whonix-Gateway, open the whonix_firewall configuration file in an editor. nano /etc/whonix_firewall.d/30_whonix_gateway_default.conf

2. Add.

WORKSTATION_TRANSPARENT_TCP=0 WORKSTATION_TRANSPARENT_DNS=0

3. Save.

4. Reload Whonix-Gateway^™ Firewall.

If you are using Qubes-Whonix^™, complete the following steps.

Qubes App Launcher (blue/grey "Q") → Whonix-Gateway ProxyVM (commonly named sys-whonix) → Reload Whonix Firewall

If you are using a graphical Whonix-Gateway, complete the following steps.

Start Menu → Applications → System → Reload Whonix Firewall

If you are using a terminal-only Whonix-Gateway, run. sudo whonix_firewall

5. Done.

Deactivating transparent proxying is complete.

This will disable transparent proxying. All applications not configured to use a SocksPort by socks proxy settings or forced to use a SocksPort by a socksifier will not be able to establish connections. This is the only way to ensure that different SocksPorts are used and also that DNS is remotely resolved through that SocksPort.

6. Test.

Optional.

• Check if Transparent DNS is disabled
• Check if Transparent TCP is disabled

IsolateSOCKSAuth

See Tor manual IsolateSOCKSAuth.

Don’t share circuits with streams for which different SOCKS authentication was provided. [...]

This is can be used with the SocksPort option.

SocksPort [address:]port|unix:path|auto [flags] [isolation flags]

IsolateSOCKSAuth is a sub option of the SocksPort option.

Qubes Specific

Qubes UpdatesProxy Stream Isolation

This chapter is for advanced users only.

Platform specific:

• Non-Qubes-Whonix: apt-get is stream isolated by uwt and redirected to Tor SocksPort. (See anon-ws-disable-stacked-tor) Therefore, every VM is using a different stream, thanks to Tor's default IsolateClientAddr option, which results in different IP source addresses (different internal network VM IPs) getting stream isolated.
• Qubes-Whonix: Security and stream isolation are unfortunately conflicting goals. Templates in Qubes are non-networked by default for better security because they don't have a network stack, hence a lower attack surface. apt-get is redirected without a network through Qubes qrexec to Whonix-Gateway localhost where Qubes tinyproxy is listening. Therefore, the information of the internal source IP address of the VM is "lost in translation" and not reaching Tor on Whonix-Gateway. Hence, there is no benefit from IsolateClientAddr. Soon (time of writing: 07 June 2024) (in testers repository) tinyproxy on Whonix-Gateway has been configured to use a dedicated Tor SocksPort. That of course does not result in IsolateClientAddr. But at least traffic by tinyproxy is no longer mixed into Tor's TransPort / DnsPort. Unfortunately, all Templates using sys-whonix as UpdatesProxy are mixed into the same stream. In conclusion, stream isolation of apt-get in Qubes-Whonix is a bit worse than stream isolation in Non-Qubes-Whonix. This situation is unlikely to change due to the technical difficulty of improving this unless contributed. There are no known steps that users could take to improve this situation.
  • Qubes tinyproxy vs apt-cacher-ng?
    • tinyproxy: Good, can at least use a Tor SocksPort.
    • apt-cacher-ng: Unsupported. Unknown if it can use SocksPort. It might support a HTTP proxy so maybe a Tor HTTPTunnelPort could be used.
  • Qubes-Whonix related:
    • remove tinyproxy from Whonix-Gateway (sys-whonix) and make Whonix Templates networked by default with Net qube set to sys-whonix
    • Qubes-Whonix UpdatesProxy user documentation
    • Torified UpdatesProxy developer documentation
  • Future: Maybe in the future after/if Create sys-ops-whonix VM for Enhanced Security and Isolation in Qubes-Whonix gets implemented, sys-ops-whonix could start a new instance of Qubes UpdatesProxy each time it receives a new connection from Qubes qrexec.

Deactivate Stream Isolation

Easy

Choose an option. Either A) or B).

• A) How to disable stream isolation. Most easy and common methods only. Or,
• B) For more options, see below.

Deactivate uwt Stream Isolation Wrapper

OPTIONAL. Usually not required. Only for special setups and people who know what they are doing.

Temporary

anondist-orig Method

Append .anondist-orig to the command you want to run. For example, instead of using.

curl 38.229.72.22

Use.

curl.anondist-orig 38.229.72.22

Environment Variable Method

Use the UWT_DEV_PASSTHROUGH environment variable.

Example. Set the UWT_DEV_PASSTHROUGH environment variable. This will disable using torsocks for all following invocations.

export UWT_DEV_PASSTHROUGH="1" curl 38.229.72.22

When running as user and using sudo, do not forget sudo parameter -E which stands for preserve environment.

sudo -E apt update

Permanently

Introduction

You can enable/disable all uwt stream isolation wrappers globally or enable/disable specific stream isolation wrappers, see uwt /etc/uwt.d/30_uwt_default.conf configuration file.

deactivate all uwt wrappers permanently

The following instructions permanently deactivate all uwt wrappers and remove stream isolation for uwt-wrapped applications system-wide. Consequently, all uwt-wrapped applications revert to the default system networking configuration.

For more granular control of uwt wrapper deactivation, see: Deactivate uwt Stream Isolation Wrapper.

1. Platform specific notice:

• Non-Qubes-Whonix^™: No platform specific notice.
• Qubes-Whonix^™: In Template. (whonix-workstation-17)

2. Open file /etc/uwt.d/50_user.conf in an editor with root rights.

Non-Qubes-Whonix^™

This box uses sudoedit for better security.

sudoedit /etc/uwt.d/50_user.conf

Qubes-Whonix^™

NOTES:

• When using Qubes-Whonix, this needs to be done inside the Template.

sudoedit /etc/uwt.d/50_user.conf

• After applying this change, shutdown the Template.
• All App Qubes based on the Template need to be restarted if they were already running.
• This is a general procedure required for Qubes and unspecific to Qubes-Whonix^™.

Others and Alternatives

• This is just an example. Other tools could achieve the same goal.
• If this example does not work for you or if you are not using Whonix, please refer to this link.

sudoedit /etc/uwt.d/50_user.conf

3. Add.

uwtwrapper_global="0"

4. Save and exit.

5. Check that the changes have taken effect. Run in terminal: uwt_settings_show

It should print

uwt INFO: disabled.

6. Done.

Deactivate Misc Proxy Settings

On the Stream Isolation page, there is a list of applications that are pre-configured to use socks proxy settings via application configuration files. To disable this the Whonix system default must be removed from the application's settings.

TODO: document and expand.

Remove proxy settings for APT repository files.

1. Platform specific notice:

• Non-Qubes-Whonix^™: No platform specific notice.
• Qubes-Whonix^™: In Template. (whonix-workstation-17)

2. If you previously onionized any repositories, that has to be undone; see Onionizing Repositories.

3. Remove any mention of tor+ in file /etc/apt/sources.list (if it was previously configured; that file is empty by default in Whonix / Kicksecure) or any file in folder /etc/apt/sources.list.d.

4. Open file /etc/apt/sources.list /etc/apt/sources.list.d/* in an editor with root rights.

Non-Qubes-Whonix^™

This box uses sudoedit for better security.

sudoedit /etc/apt/sources.list /etc/apt/sources.list.d/*

Qubes-Whonix^™

NOTES:

• When using Qubes-Whonix, this needs to be done inside the Template.

sudoedit /etc/apt/sources.list /etc/apt/sources.list.d/*

• After applying this change, shutdown the Template.
• All App Qubes based on the Template need to be restarted if they were already running.
• This is a general procedure required for Qubes and unspecific to Qubes-Whonix^™.

Others and Alternatives

• This is just an example. Other tools could achieve the same goal.
• If this example does not work for you or if you are not using Whonix, please refer to this link.

sudoedit /etc/apt/sources.list /etc/apt/sources.list.d/*

5. Remove any mention of tor+.

6. Done.

The process of removing proxy settings from APT repository files is now complete.

Remove proxy settings for Tor Browser Downloader by Whonix.

1. Platform specific notice:

• Non-Qubes-Whonix: No platform specific notice.
• Qubes-Whonix: In Template. (whonix-workstation-17)

2. Open file /etc/torbrowser.d/50_user.conf in an editor with root rights.

Non-Qubes-Whonix^™

This box uses sudoedit for better security.

sudoedit /etc/torbrowser.d/50_user.conf

Qubes-Whonix^™

NOTES:

• When using Qubes-Whonix, this needs to be done inside the Template.

sudoedit /etc/torbrowser.d/50_user.conf

• After applying this change, shutdown the Template.
• All App Qubes based on the Template need to be restarted if they were already running.
• This is a general procedure required for Qubes and unspecific to Qubes-Whonix^™.

Others and Alternatives

• This is just an example. Other tools could achieve the same goal.
• If this example does not work for you or if you are not using Whonix, please refer to this link.

sudoedit /etc/torbrowser.d/50_user.conf

3. Paste.

TB_NO_TOR_CON_CHECK=1 CURL_PROXY="--fail"

4. Save and exit.

5. Done.

Proxy settings have been removed from Tor Browser Downloader by Whonix (and Mullvad Browser by Kicksecure developers).

For some applications, this is impossible:

• sdwdate
• OnionShare
• Ricochet IM

These applications can only talk to Tor Onion Services directly and cannot be configured to use the system default. Therefore you can only deactivate sdwdate and/or not use applications like OnionShare and Ricochet IM.

Tor Browser Remove Proxy Settings

If you would like to remove proxy settings from Tor Browser, see below.

Introduction

This configuration results in Tor Browser no longer using proxy settings. With no proxy set, Tor Browser uses the (VM) system's default networking. This is identical to any other application inside Whonix-Workstation^™ that has not been explicitly configured to use Tor via socks proxy settings or a socksifier. This setting is also called transparent torification.

Why is this difficult?

This is difficult and may not work for you.

To learn why this is difficult, please press on Expand on the right.

Tor Browser, which is developed by upstream, The Tor Project (TPO), an independent entity has hard configured to use Tor as a proxy.

• Upstream does not support user using Tor Browser with an additional extra proxy at the end of the chain, i.e.: user → Tor → proxy → destination
• Upstream does also not support using Tor Browser with a proxy other than Tor, i.e.: user → custom proxy → destination. This may or may not currently be possible but upstream does not provide documentation on how to do this.
• Upstream does also not support using Tor Browser with a VPN instead of Tor, i.e. user → VPN → destination.
• Upstream does also not support using Tor Browser with a VPN in addition before Tor, i.e. user → Tor → VPN → destination.

That makes sense from TPO's perspective as a project that maintains a browser that should always connect using the Tor network. Due to that perspective, proxy settings have been removed from Tor Browser to avoid user confusion and accidental misconfiguration. Little attention is spend on custom proxy settings. That, from TPO's perspective is assumed to only make sense for users using a Tor transparent proxy and that are already running Tor on a different computer in their LAN. Only a minority of users is using such configurations.

Because of this organisational and technical background, the highly specialized use case of configuring Tor Browser running inside Whonix-Workstation^™ to use an additional proxy (user -> Tor -> proxy -> destination) is difficult to accomplish.

To learn more about this organisational and technical background see also Linux User Experience versus Commercial Operating Systems

COMMUNITY SUPPORT ONLY : THIS wiki CHAPTER only is only supported by the community. Whonix developers are very unlikely to provide free support for this content. See Community Support for further information, including implications and possible alternatives.

Note: This action will break both Stream Isolation for Tor Browser and Tor Browser's SOCKS username for a request based on first party domain feature. This worsens the web fingerprint and leads to pseudonymous (not anonymous) connections. To mitigate these risks, consider using More than one Tor Browser in Whonix, or preferably Multiple Whonix-Workstation^™.

Local socks proxy Method

This method works for removal of proxy settings but is rather lengthy and complicated. In case the user wants to have a look anyhow, please press on Expand on the right.

Since other methods to configure Tor Browser to use system default networking are broken due to Tor Browser changes by upstream, this new local socks proxy method stops anon-ws-disable-stacked-tor local port 9150 redirection to Whonix-Gateway^™ 9150 (where a Tor SocksPort is listening). As a replacement, a local socks proxy listens on Whonix-Workstation local port 9150 which then forwards the traffic using system default networking. In result, if the user is using a VPN inside Whonix-Workstation or in a VPN-Gateway wretched between Whonix-Gateway^™ and Whonix-Workstation, Tor Browser would use the VPN.

In this documentation, Dante is used as a local socks proxy. Development notes are kept on Dev/Dante.

1. Legacy notices.

• New users, that did not apply instructions from this page again: No special notice.
• Existing users: See below.

A few settings need to be undone.

• A) Previous changes to /etc/environment as documented previously for other methods need to be undone.
• B) Tor Browser needs to be re-installed. This is because undoing the previous configuration is difficult and undocumented.

2. Stop default anon-ws-disable-stacked-tor service for port 9150.

• Non-Qubes-Whonix: In Whonix-Workstation.
• Qubes-Whonix: In whonix-workstation-17 Template.

sudo systemctl stop anon-ws-disable-stacked-tor_autogen_port_9150.socket sudo systemctl stop anon-ws-disable-stacked-tor_autogen_port_9150.service sudo systemctl stop anon-ws-disable-stacked-tor_autogen__run_anon-ws-disable-stacked-tor_127.0.0.1_9150.sock.socket sudo systemctl stop anon-ws-disable-stacked-tor_autogen__run_anon-ws-disable-stacked-tor_127.0.0.1_9150.sock.service

3. Prevent default anon-ws-disable-stacked-tor systemd unit from starting.

• Non-Qubes-Whonix: In Whonix-Workstation.
• Qubes-Whonix: In whonix-workstation-17 Template.

sudo systemctl mask anon-ws-disable-stacked-tor_autogen_port_9150.socket sudo systemctl mask anon-ws-disable-stacked-tor_autogen_port_9150.service sudo systemctl mask anon-ws-disable-stacked-tor_autogen__run_anon-ws-disable-stacked-tor_127.0.0.1_9150.sock.socket sudo systemctl mask anon-ws-disable-stacked-tor_autogen__run_anon-ws-disable-stacked-tor_127.0.0.1_9150.sock.service

4. Install the local socks proxy server.

• Non-Qubes-Whonix: In Whonix-Workstation.
• Qubes-Whonix: In whonix-workstation-17 Template.

A) Add Debian source repository.

Open file /etc/apt/sources.list.d/debian-src.list in an editor with root rights.

Non-Qubes-Whonix^™

This box uses sudoedit for better security.

sudoedit /etc/apt/sources.list.d/debian-src.list

Qubes-Whonix^™

NOTES:

• When using Qubes-Whonix, this needs to be done inside the Template.

sudoedit /etc/apt/sources.list.d/debian-src.list

• After applying this change, shutdown the Template.
• All App Qubes based on the Template need to be restarted if they were already running.
• This is a general procedure required for Qubes and unspecific to Qubes-Whonix^™.

Others and Alternatives

• This is just an example. Other tools could achieve the same goal.
• If this example does not work for you or if you are not using Whonix, please refer to this link.

sudoedit /etc/apt/sources.list.d/debian-src.list

Paste.

deb-src https://deb.debian.org/debian bookworm main contrib non-free

Save and exit.

sudo apt update

B) Install build dependencies.

sudo apt build-dep dante-server

C) Get dante source code.

apt-get source dante-server

D) Open the dante accesscheck.c source file.

mousepad ~/dante-1.4.2+dfsg/sockd/accesscheck.c

Paste the contents. Here we rewrite the authentication method to always return true. For the reasons see Dev/Dante.

/* * Copyright (c) 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2005, 2006, 2008, * 2009, 2010, 2011, 2012, 2013 * Inferno Nettverk A/S, Norway. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. The above copyright notice, this list of conditions and the following * disclaimer must appear in all copies of the software, derivative works * or modified versions, and any portions thereof, aswell as in all * supporting documentation. * 2. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by * Inferno Nettverk A/S, Norway. * 3. The name of the author may not be used to endorse or promote products * derived from this software without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * * Inferno Nettverk A/S requests users of this software to return to * * Software Distribution Coordinator or sdc@inet.no * Inferno Nettverk A/S * Oslo Research Park * Gaustadalléen 21 * NO-0349 Oslo * Norway * * any improvements or extensions that they make and grant Inferno Nettverk A/S * the rights to redistribute these changes. * */ #include "common.h" static const char rcsid[] = "$Id: accesscheck.c,v 1.89 2013/10/27 15:24:42 karls Exp $"; int usermatch(auth, userlist) const authmethod_t *auth; const linkedname_t *userlist; { /* const char *function = "usermatch()"; */ const char *name; if ((name = authname(auth)) == NULL) return 0; /* no username, no match. */ do if (strcmp(name, userlist->name) == 0) break; while ((userlist = userlist->next) != NULL); if (userlist == NULL) return 0; /* no match. */ return 1; } int groupmatch(auth, grouplist) const authmethod_t *auth; const linkedname_t *grouplist; { const char *function = "groupmatch()"; const char *username; struct passwd *pw; struct group *groupent; SASSERTX(grouplist != NULL); if ((username = authname(auth)) == NULL) return 0; /* no username, no match. */ /* * First check the primary group of the user against grouplist. * If the groupname given there matches, we don't need to go through * all users in the list of group. */ if ((pw = getpwnam(username)) != NULL && (groupent = getgrgid(pw->pw_gid)) != NULL) { const linkedname_t *listent = grouplist; do if (strcmp(groupent->gr_name, listent->name) == 0) return 1; while ((listent = listent->next) != NULL); } else { if (pw == NULL) slog(LOG_DEBUG, "%s: unknown username \"%s\"", function, username); else if (groupent == NULL) slog(LOG_DEBUG, "%s: unknown primary groupid %ld", function, (long)pw->pw_gid); } /* * Go through grouplist, matching username against each groupmember of * all the groups in grouplist. */ do { char **groupname; if ((groupent = getgrnam(grouplist->name)) == NULL) { swarn("%s: unknown groupname \"%s\"", function, grouplist->name); continue; } groupname = groupent->gr_mem; while (*groupname != NULL) { if (strcmp(username, *groupname) == 0) return 1; /* match. */ ++groupname; } } while ((grouplist = grouplist->next) != NULL); return 0; } #if HAVE_LDAP int ldapgroupmatch(auth, rule) const authmethod_t *auth; const rule_t *rule; { const char *function = "ldapgroupmatch()"; const linkedname_t *grouplist; const char *username; char *userdomain, *groupdomain; int retval; if ((username = authname(auth)) == NULL) return 0; /* no username, no match. */ #if !HAVE_GSSAPI if (!rule->state.ldap.ldapurl) SERRX(rule->state.ldap.ldapurl != NULL); #endif /* !HAVE_GSSAPI */ if ((userdomain = strchr(username, '@')) != NULL) ++userdomain; if (userdomain == NULL && *rule->state.ldap.domain == NUL && rule->state.ldap.ldapurl == NULL) { slog(LOG_DEBUG, "%s: cannot check ldap group membership for user %s: " "user has no domain postfix and no ldap url is defined", function, username); return 0; } if ((retval = ldap_user_is_cached(username)) >= 0) return retval; /* go through grouplist, matching username against members of each group. */ grouplist = rule->ldapgroup; do { char groupname[MAXNAMELEN]; slog(LOG_DEBUG, "%s: checking if user %s is member of ldap group %s", function, username, grouplist->name); STRCPY_ASSERTLEN(groupname, grouplist->name); if ((groupdomain = strchr(groupname, '@')) != NULL) { *groupdomain = NUL; /* separates groupname from groupdomain. */ ++groupdomain; } if (groupdomain != NULL && userdomain != NULL) { if (strcmp(groupdomain, userdomain) != 0 && strcmp(groupdomain, "") != 0) { slog(LOG_DEBUG, "%s: userdomain \"%s\" does not match groupdomain " "\"%s\" and groupdomain is not default domain. " "Trying next entry", function, userdomain, groupdomain); continue; } } if (ldapgroupmatches(username, userdomain, groupname, groupdomain, rule)){ cache_ldap_user(username, 1); return 1; } } while ((grouplist = grouplist->next) != NULL); cache_ldap_user(username, 0); return 0; } #endif /* HAVE_LDAP */ int accesscheck(s, auth, src, dst, emsg, emsgsize) int s; authmethod_t *auth; const struct sockaddr_storage *src, *dst; char *emsg; size_t emsgsize; { int match, authresultisfixed; match = 1; /* * HACK-FORK-EDIT-OK */ return match; }

E) Change directory into the dante source code folder.

pushd dante-1.4.2+dfsg

F) Build the Debian package.

dpkg-buildpackage -b --no-sign

E) Change directory back to the home folder.

popd

F) Install the modified dante package.

sudo dpkg -i dante-server_1.4.2+dfsg-7_amd64.deb

G) Block updates of dante-server.

sudo apt-mark hold dante-server

5. Open file /etc/danted.conf in an editor with root rights.

Non-Qubes-Whonix^™

This box uses sudoedit for better security.

sudoedit /etc/danted.conf

Qubes-Whonix^™

NOTES:

• When using Qubes-Whonix, this needs to be done inside the Template.

sudoedit /etc/danted.conf

• After applying this change, shutdown the Template.
• All App Qubes based on the Template need to be restarted if they were already running.
• This is a general procedure required for Qubes and unspecific to Qubes-Whonix^™.

Others and Alternatives

• This is just an example. Other tools could achieve the same goal.
• If this example does not work for you or if you are not using Whonix, please refer to this link.

sudoedit /etc/danted.conf

6. Local socks proxy configuration.

• Non-Qubes-Whonix: In Whonix-Workstation.
• Qubes-Whonix: In whonix-workstation-17 Template.

Delete all contents from the file and replace it with the following configuration.

debug: 0 logoutput: stderr internal: 127.0.0.1 port = 9150 external: eth0 socksmethod: none username clientmethod: none user.privileged: root user.notprivileged: root user.libwrap: root # allow connections only from localhost client pass { from: 127.0.0.1/8 port 1-65535 to: 0.0.0.0/0 log: connect disconnect error # comment on some logs if you don't want to keep them } socks pass { from: 0.0.0.0/0 to: 0.0.0.0/0 command: bind connect udpassociate log: error connect disconnect iooperation }

7. Restart the local socks proxy.

This is to apply the changed configuration and to test if the configuration is valid.

• Non-Qubes-Whonix: In Whonix-Workstation.
• Qubes-Whonix: In whonix-workstation-17 Template.

sudo systemctl restart danted.service

8. tb-starter Configuration

• Non-Qubes-Whonix: In Whonix-Workstation.
• Qubes-Whonix: In whonix-workstation-17 Template.

Stop Tor from using unix domain socket files for socks so it uses socks on IP 127.0.0.1 port 9150 instead.

Open file /etc/torbrowser.d/50_user.conf in an editor with root rights.

Non-Qubes-Whonix^™

This box uses sudoedit for better security.

sudoedit /etc/torbrowser.d/50_user.conf

Qubes-Whonix^™

NOTES:

• When using Qubes-Whonix, this needs to be done inside the Template.

sudoedit /etc/torbrowser.d/50_user.conf

• After applying this change, shutdown the Template.
• All App Qubes based on the Template need to be restarted if they were already running.
• This is a general procedure required for Qubes and unspecific to Qubes-Whonix^™.

Others and Alternatives

• This is just an example. Other tools could achieve the same goal.
• If this example does not work for you or if you are not using Whonix, please refer to this link.

sudoedit /etc/torbrowser.d/50_user.conf

Paste.

unset TOR_SOCKS_IPC_PATH

Save and exit.

9. Platform specific notice:

• Non-Qubes-Whonix: No special notice required.
• Qubes-Whonix: Shutdown Template. Once done, restart App Qube.

10. Start Tor Browser.

• Non-Qubes-Whonix: In Whonix-Workstation.
• Qubes-Whonix: In Whonix-Workstation App Qube.

torbrowser

Tor Browser should now be using system default networking thanks to the local socks proxy.

No additional configuration of Tor Browser is required.

11. Done.

Older Methods:

For older methods, which might be broken due to Tor Browser changes by upstream, please press on Expand on the right.

To enable transparent torification (no proxy setting), set the TOR_TRANSPROXY=1 environment variable. There are several methods, but the simplest is the /etc/environment Method.

Note: Choose only one method to enable transparent torification.

/etc/environment Method

This will apply to the whole environment, including any possible custom locations of Tor Browser installation folders.

1. Platform specific notice.

• Non-Qubes-Whonix^™: No platform specific notice.
• Qubes-Whonix^™: In Template. (whonix-workstation-17)

2. Open file /etc/environment in an editor with root rights.

Non-Qubes-Whonix^™

This box uses sudoedit for better security.

sudoedit /etc/environment

Qubes-Whonix^™

NOTES:

• When using Qubes-Whonix, this needs to be done inside the Template.

sudoedit /etc/environment

• After applying this change, shutdown the Template.
• All App Qubes based on the Template need to be restarted if they were already running.
• This is a general procedure required for Qubes and unspecific to Qubes-Whonix^™.

Others and Alternatives

• This is just an example. Other tools could achieve the same goal.
• If this example does not work for you or if you are not using Whonix, please refer to this link.

sudoedit /etc/environment

3. Add the following line.

TOR_TRANSPROXY=1 ## newline at the end

4. Save and exit.

5. Reboot.

Reboot is required to make changes to configuration file /etc/environment take effect.

6. Done.

/etc/environment method configuration has been completed.

Tor Browser Settings Changes

This step is required since Tor Browser 10.

1. Platform specific notice.

• Non-Qubes-Whonix: No platform specific notice.
• Qubes-Whonix: In App Qube. (anon-whonix)

2. Tor Browser → URL bar → Type: about:config → Press Enter key. → search for and modify

3. network.dns.disabled → set to false

4. extensions.torbutton.launch_warning → set to false

Undo

Reverting this change is undocumented. Simply unsetting that environment variable will not work due to Tor Browser limitations. The easiest way to undo this setting is to install a fresh instance of Tor Browser (please contribute to these instructions)!

Command Line Method

1. Platform specific notice:

• Non-Qubes-Whonix: No platform specific notice.
• Qubes-Whonix: In App Qube. (anon-whonix)

2. Navigate to the Tor Browser folder.

cd ~/.tb/tor-browser

3. Every time Tor Browser is started, run the following command to set the TOR_TRANSPROXY=1 environment variable.

TOR_TRANSPROXY=1 ./start-tor-browser.desktop

4. Done.

start-tor-browser Method

This only applies to a single instance of the Tor Browser folder that is configured. This method may not persist when Tor Browser is updated.

1. Platform specific notice:

• Non-Qubes-Whonix: No platform specific notice.
• Qubes-Whonix: In App Qube. (anon-whonix)

2. Find and open start-tor-browser in the Tor Browser folder with an editor.

This is most likely found in ~/.tb/tor-browser/Browser/start-tor-browser below #!/usr/bin/env bash.

3. Set.

export TOR_TRANSPROXY=1

4. Done.

start-tor-browser Method configuration has been completed.

Ignore Tor Button's Open Network Settings

Whonix has disabled the Open Network Settings... menu option in Tor Button. Read the footnote for further information.

Nested Execution

uwt version 4.0-1 and above protects form endless nested execution which could likely lead to a locked up session by aborting after 10 times an uwt wrapped application calling another uwt wrapped application. In that case, you would see the following error message.

uwtwrapper uwt wrapper ERROR: More than uwtwrapper_counter 10 nested executions (uwtwrapper_max: 10).

This is most likely happening due to two symlinks pointing to each other resulting in endless execution. However, should there be any cases (none could be foreseen at development time) where this is legitimate, feel free to change the setting responsible for aborting execution. Please also consider reporting your use case in Whonix forums so perhaps a better fix for this can be found.

Open file /etc/uwt.d/50_user.conf in an editor with root rights.

Non-Qubes-Whonix^™

This box uses sudoedit for better security.

sudoedit /etc/uwt.d/50_user.conf

Qubes-Whonix^™

NOTES:

• When using Qubes-Whonix, this needs to be done inside the Template.

sudoedit /etc/uwt.d/50_user.conf

• After applying this change, shutdown the Template.
• All App Qubes based on the Template need to be restarted if they were already running.
• This is a general procedure required for Qubes and unspecific to Qubes-Whonix^™.

Others and Alternatives

• This is just an example. Other tools could achieve the same goal.
• If this example does not work for you or if you are not using Whonix, please refer to this link.

sudoedit /etc/uwt.d/50_user.conf

Set uwtwrapper_max to a value more suitable for you.

uwtwrapper_max=100

Alternatively you could completely disable the nested execution protection.

nested_protection() { true }

Save and exit.

Done.

Development

Information

See also the Tor manual on SocksPort, HTTPTunnelPort, TransPort and DnsPort.

SocksPort

A SocksPort is a listen port by Tor which accepts traffic using the socks protocol.

Using a SocksPort is possible by using either:

• application specific socks proxy settings
• wrapper method such as torsocks (which can be automatically prepended using uwt

Traffic on separate SocksPorts is stream isolated by Tor default.

HTTPTunnelPort

A HTTPTunnelPort is a listen port by Tor which accepts traffic using the HTTP CONNECT method.

This is a new feature of Tor.

Traffic on separate HTTPTunnelPorts is stream isolated by Tor default.

Forum discussion:
https://forums.whonix.org/t/tor-can-now-serve-as-http-proxy-httptunnelport/5373

TransPort

TransPort is a feature where Tor accepts raw traffic on a listen port if redirected there using iptables. See also TransparentProxy.

When using Transparent Proxying (default in Whonix) (see this page for Transparent Proxying for more information), all applications that do not use a SocksPort or HTTPTunnelPort will fall back to be using Tor's TransPort for TCP. I.e. using system default networking. This is also called transparent proxying.

There is no stream isolation for TransPort connections unless originating from a separate Whonix-Workstation.

DnsPort

Similar to above but for DNS. All applications that do not use a SocksPort or HTTPTunnelPort will fall back to be using Tor's DnsPort for DNS.

torsocks

All uwt wrapped applications will be stream isolated by torsocks /etc/tor/torsocks.conf setting IsolatePID 1.

To test this, run multiple times the following command.

scurl https://check.torproject.org | grep IP

Tests

1. Applications which internally use curl.

sudo update-command-not-found sudo update-flashplugin-nonfree --install --verbose

2. Applications which is uwt wrapped itself and internally uses ssh.

git push origin master

3. Enigmail.

Debugging / List of all uwt wrappers

sudo dpkg-divert --list ls -la /usr/bin/ssh

Deactivating an uwt wrapper

Example:

sudo unlink /usr/bin/ssh sudo dpkg-divert --rename --remove /usr/bin/ssh

Check if Transparent DNS is disabled

Note: The following test should be performend in Whonix-Workstation (Qubes-Whonix: App Qube anon-whonix).

Test.

nslookup check.torproject.org ; echo $?

Expected output.

;; connection timed out; no servers could be reached

1

If it shows something else, such as a resolved IP, the Transparent DNS is enabled.

Check if Transparent TCP is disabled

Note: The following test should be performend in Whonix-Workstation (Qubes-Whonix: App Qube anon-whonix).

Test.

UWT_DEV_PASSTHROUGH=1 curl 116.202.120.181 ; echo $?

Expected output.

curl: (7) couldn't connect to host
7

If it shows something else, such as the html source code, then Transparent TCP is enabled.

Check if Transparent Proxying is disabled

Note: The following test should be performend in Whonix-Workstation (Qubes-Whonix: App Qube anon-whonix).

Test.

UWT_DEV_PASSTHROUGH=1 curl https://check.torproject.org/ ; echo $?

Expected output.

curl: (6) Couldn't resolve host 'check.torproject.org'
6

If it shows something else, such as the html source code, then Transparent Proxying is enabled.

Check if an Application is properly using Stream Isolation

• Same as leak testing as if Whonix is not involved.
• Also... A weaker test... The transparent proxying disablement test.

Disable transparent proxying of DNS and TCP as per #Better Protection.

Check that worked as per:

• Check if Transparent DNS is disabled
• Check if Transparent TCP is disabled

That is because it doesn't work without transparent proxying (system default networking), meaning application unable to use network normally, then there is a certain socks leak, meaning certainly some traffic which requires system default networking. In case of:

• clearnet operating systems: a clearnet leak
• Whonix: a stream isolation violation

This is only weak test since an application could very likely try socks first and if socks fails, fall back to system default networking. Therefore, normal leak testing is required.

• Internet research if application was specifically designed for use with Tor.
• Internet research if application was specifically audited for clearnet leaks.
• Discussion with software contributor about this if these haven't already happened.
• https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorifyHOWTO#Howtoreviewanapplication
• https://lists.torproject.org/pipermail/tor-talk/2012-April/024010.html
• https://gitlab.torproject.org/legacy/trac/-/issues/5553
• corridor - Tor traffic whitelisting gateway

Add new uwt wrapper

Emulate this commit.

Sources

• Separate streams across circuits by connection metadata
• tor-talk Operating system updates / software installation behind Tor Transparent Proxy
• tor-talk Awareness for identity correlation through circuit sharing is almost zero.
• tor-talk Tor's stream isolation features defaults Question
• tor-talk Tor's stream isolation features defaults Answer
• Tails-dev separate Tor streams
• Tails separate Tor streams
• Tails-dev Please review Tails stream isolation plans
• Tails Design: Tor stream isolation

Stream Isolation Graphic has been contributed by: Cuan Knaggs – graphic and web design revolver print media – web design – web development – cms – e-commerce

References

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