- 1 Stream Isolation
- 1.1 Introduction
- 1.2 How to mitigate identity correlation
- 1.3 Deactivate uwt Stream Isolation Wrapper
- 1.4 Development
- 1.5 Sources
- 1.6 References
If you do not explicitly take action against this and install custom applications, you risk that different activities, let's say Web (Chromium or similar) or IRC (mIRC or similar) go through the same Tor circuit and exit relay. Even though you would still be anonymous, i.e. the Tor exit relay would still not know your real IP/location, they can easily correlate those activities issued 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 dedicated SocksPort's per application results in taking different routes through the Tor network per application. Not necessarily all nodes (first, second, third) get replaced by Tor. Sometimes just the first, sometimes just the second, sometimes just the third, and sometimes multiple nodes change.
Whonix 0.2.1 and above implement protection against identity correlation through circuit sharing, however, for better privacy, you are still advised to understand a bit of the technical background. Since Tor version 0.2.3, different Socks,- Dns-, or TransPorts go through different circuits, therefore preventing identity correlation. Whonix configures most applications that come preinstalled with Whonix to use 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).
Any other traffic (i.e. custom installed applications, misc applications, such as nslookup, go through Tor's Dns-, and/or TransPort (can be optionally disabled, see below).
Applications in Whonix 0.2.1 and above configured to prevent identity correlation through circuit sharing:
|Tor Browser||yes||yes||socks proxy settings||9150 ||Tor Browser|
|XChat||yes||yes||socks proxy settings||9101||Chat|
|Thunderbird with TorBirdy||no||yes||socks proxy settings||-||Mozilla Thunderbird with TorBirdy|
|Instant Messenger||no||no||socks proxy settings||port prepared, IP 192.168.0.10, port 9103||Chat|
|aptitude||yes||no||-||-||in forum (will be installed by default in Whonix 6 and above)|
|sdwdate||yes||yes||socks proxy settings||-||-|
|whonixcheck||yes||yes||socks proxy settings||-||-|
|BitCoin||no||no||socks proxy settings||port prepared, IP 192.168.0.10, port 9111||Money|
|privoxy||no||no||socks proxy settings||port prepared, IP 192.168.0.10, port 9112||-|
|polipo||no||no||socks proxy settings||port prepared, IP 192.168.0.10, port 9113||-|
|torbrowser update script||yes||yes||socks proxy settings||-||Tor Browser|
|apt-cacher-ng||no||no||uwt wrapper||-||helper script with comments prepared, see /usr/bin/apt-cacher-ng_uwt|
|TorChat||no||yes||settings, socks proxy settings, connects only to hidden services||-||Chat|
|mixmaster||yes||yes||settings (connects only to hidden services)||-||Mixmaster|
Whonix 6 and above: KDE application wide proxy settings (no KDE applications with network activity pre-installed, pre-configured socks proxy settings, port 9122)
Whonix 6 and above: GNOME application wide proxy settings (no GNOME applications with network activity pre-installed, not pre-configured, port prepared, port 9123)
The required socks proxy settings were setup by the Whonix build scripts. uwt wrappers are set up on Whonix-Gateway and on Whonix-Workstation under uwt is a wrapper around torsocks, which is also already installed to ..
- Example, each time you run a uwt wrapped application, i.e. simply type apt-get in console, the uwt wrapper will run. It adds uwt before apt-get. For curiosity check . The uwt wrapper then runs . 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 #Deactivate_uwt_Stream_Isolation_Wrapper. in console, do run . 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
- When running /usr/bin/apt-get.real directly it 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 ok.
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.
Different tabs and websites in Tor Browser are not isolated until Tor upstream feature "Tor Browser should set SOCKS username for a request based on referer" gets implemented. Limited workarounds are described below.
If you install custom software on Whonix-Workstation, and want to prevent identity correlation through 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.
Hidden services are automatically separated from each other.
- Whonix-Workstation 127.0.0.1:9150 gets redirected to 192.168.0.10:9150 by rinetd. See on Whonix-Workstation file /etc/rinetd. Changing proxy settings in Tor Browser has proven to be unreliable. At some point Tor Button may change its internals and therefore break something again. Keeping the default settings and not requiring any changes in Tor Browser seems like the best way to support compatibility in long run and also is simplest in case manually updating Tor Browser is required again in future. breaks and
- If you used to use only one SocksPort with the common torification methods, the same thing happened.
- Also the current (March 2012) Tor Browser Bundle is affected, all Firefox Tabs can be correlated to the same identity until the circuit is automatically changed by Tor.
- Tails, which is officially listed on torproject.org was also affected. Tails done Todo item.
How to mitigate identity correlation
Most applications which come with Whonix 0.2.1 and above are already configured to prevent identity correlation through circuit sharing, you really should read the introduction above.
The only traffic going through TransPort by default is whonixcheck when testing the TransPort. If that is of concern to you, it can be disabled in whonixcheck. Just comment out the "check_tor "TransPort"" in /usr/bin/whonixcheck in that case.
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 circuit, thus identity correlation is at risk.
To protect against this, you have to set up per-application SOCKS ports in Whonix-Gateway.
On Whonix-Gateway in /etc/tor/torrc (on github) are already a lot custom socks ports prepared for custom installed applications:
- Without IsolateDestAddr and without IsolateDestPort: SocksPort 192.168.0.10:9152 to 9159
- With IsolateDestAddr, but without IsolateDestPort: SocksPort 192.168.0.10:9160 to 9169
- Without IsolateDestAddr, but with IsolateDestPort: SocksPort: 192.168.0.10:9170 to 9179
- With IsolateDestAddr and with IsolateDestPort: SocksPort: 192.168.0.10:9180 to 9189
- If they those are not enough, you can add your own ones.
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.
You can point your applications, where you want to prevent identity correlation though circuit sharing, to those SocksPorts. Each custom installed application has to be torified, for directions how to do that use the Torify HOWTO.
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's setup provides protection against IP leaks through protocol leaks.
- If you do not correctly torify, no connections will be possible.
- 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. You can prevent that, be out commenting (# in front) DnsPort in /etc/tor/torrc on the Whonix-Gateway and by removing the DNS redirection firewall rule from /usr/bin/whonix_firewall.
- Do not use a local DNS resolver, as all DNS requests would be executed by the same circuit.
- Other leaks, such as applications not honoring the proxy settings / wrapper, ICMP or UDP leaks do not apply to Whonix.
For best protection against identity correlation:
Read the advice above and on Whonix-Gateway:
Deactivate KDE / GNOME - application wide proxy settings...
- Whonix 6 and above: Because those proxy settings are not application specific, but rather force all KDE / GNOME applications through the same SocksPort (no KDE / GNOME applications which use the internet preinstalled by default), deactivating those KDE / GNOME - wide proxy settings gives better control about stream isolation.
To deactivate TransPort and DnsPort...
- See WORKSTATION_TRANSPARENT_TCP in /etc/whonix_firewall.d/30_default.
- See WORKSTATION_TRANSPARENT_DNS in /etc/whonix_firewall.d/30_default.
- Reload whonix_firewall ( ) or simply reboot.
Although not strictly required, you could additionally, comment out:
- TransPort in TODO: /usr/share/tor/tor-service-defaults-torrc (this file may get overwritten when Whonix gets updated) or /etc/tor/torrc
- DnsPort in TODO: /usr/share/tor/tor-service-defaults-torrc (this file may get overwritten when Whonix gets updated) or /etc/tor/torrc
- And restart Tor. (sudo service tor restart)
This will disable transparent proxying. All applications not configured to use a SocksPort or forced to use a SocksPort (use uwt) will not be able to establish connections. This is the only way to ensure, that different SocksPorts are used and that also DNS is remotely resolved through that SocksPort.
Total protection is only possible, if you honor the advice above and only use one application per session and always revert to a fresh image or use more than one Whonix-Workstation. Multiple Whonix-Workstations (using different internal IP's) are automatically separated by Tor (IsolateClientAddr is Tor's default).
Limited workarounds for Tor Browser
1. Weakest: Close Tor Browser, go to Whonix-Gateway, start arm, press "n" for new identity, restart Tor Browser. (Will be simpler in next Whonix version, Tor Buttons new identity feature will just work.)
2. Better: Install a second browser and configure it to use its own SocksPort, see More than one Tor Browser in Whonix.
3. Even better: Use multiple Whonix-Workstations.
IsolateDestAddr and IsolateDestPort for Tor Browser (Recommended against!)
(Recommended against!) If you are interested anyway, see footnote .
Deactivate uwt Stream Isolation Wrapper
OPTIONAL. Usually not required. Only for special setups and people who know what they are doing.
You can enable/disable all uwt stream isolation wrappers globally or enable/disable specific stream isolation wrappers, see uwtconfiguration file.
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
Debugging / List of all uwt wrappers
sudo dpkg-divert --list
ls -la /usr/bin/ssh
Deactivating an uwt wrapper
sudo unlink /usr/bin/ssh sudo dpkg-divert --rename --remove /usr/bin/ssh
- 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 revlover print media – web design – web development – cms – e-commerce
- (Recommended against!)
As a workaround you could enable IsolateDestAddr and IsolateDestPort for the Tor Browser.
This comes at great performance costs, especially for websites with lots of 3rd party content. It will not isolate connections to different websites on a shared server and it will create new circuits for every IP address you connect to (e.g. it will isolate subdomains if they use different IPs). It will also let you stand out more from other Tor Browser users, because almost no one is using it that way. Generally, for these reasons you should not enable this feature. Instead close the browser and get a "new identity" through arm on the gateway if you want to separate activities inside Tor Browser. If you want to do this anyway, follow the following instructions.
On Whonix-Gateway open /etc/tor/torrc'.
sudo nano /etc/tor/torrc
SocksPort 192.168.0.10:9150 IsolateDestAddr IsolateDestPort
sudo service tor reload
Log in | OpenID | Contact | Impressum | Datenschutz | Haftungsausschluss