{{Header}} {{#seo: |title=Stream Isolation |description=Prevent Identity Correlation through Circuit Sharing by using Tor Stream Isolation. }}
* [[Stream_Isolation/Easy|short stream isolation summary]] * [[Stream Isolation|all information below]]
{{intro| Prevent Identity Correlation through Circuit Sharing by using Tor Stream Isolation. }} [[File:Streamisolationme.jpg|thumb|Old illustrative {{project_name_short}} stream isolation image.]] __TOC__ == Introduction == === Essentials === * No common term without Tor: If the internet is used normally, without Tor, a proxy, or VPN, there is no widely used term for this. This could be coined "connecting over clearnet". * Tor Browser on the host is application-limited: When using Tor without {{project_name_short}} such as when using the Tor Browser Bundle on a host operating system such as Windows or Debian, only the Tor Browser Bundle connects over Tor. All other applications are still using clearnet. * {{project_name_short}} torifies system traffic via the gateway: In case of {{project_name_short}}: {{TorifiedGateway}} * Two distinct issues: There are two different issues. ** IP Hiding: {{project_name_short}} provides [[Reliable IP Hiding]] in any case irrespective of applications (such as [[Other Browsers|browsers]], ssh, [[Remote_Administration#Remmina|Remmina]]), activities (such as [[Remote Administration]]), or protocols such as TCP, [[Tor#DNS|DNS]], [[Tor#ICMP|ICMP]], [[Tor#UDP|UDP]], RDP). Using helper utilities such as torsocks, torify or configurations such as Tor SocksPorts is not required for IP concealment. In context of anonymity, hiding of IP addresses is of absolutely crucial importance. ** Stream Isolation: Provides additional privacy protection by preventing correlation between different applications' traffic. Stream isolation aware applications; using helper utilities such as torsocks; and/or configurations such as Tor SocksPort are required. Some are already pre-configured. Compared to IP hiding, stream isolation is a detail optimization precaution but not of critical importance. === Transparent Proxy === This chapter explains what a Transparent Proxy is. It is required knowledge in order to understand the following chapters. Terminology: * Meaning of transparent proxying: Transparent proxying means, simplified and [[unspecific|unspecific to {{project_name_short}}]]:
An application can connect without requiring additional configuration.
* Clearnet Firefox on the host: Use Firefox on host operating system without Tor or any proxy/VPN without {{project_name_short}} involved: It is not clear this should be called "transparent proxying". It is probably best not to call it that way to avoid confusion. In that case, the home router is likely doing "transparent proxying". A proxy that is transparent. It does things for the user/program without the user necessarily having to know anything about it. * Tor Browser on the host: Using Tor Browser on the host without {{project_name_short}} involved: This is an example of "no transparent proxying available". Tails used to have transparent proxying (could use any application without configuration). Nowadays Tails has no transparent proxying. (Most) Custom installed applications (example: Mozilla Firefox) won't connect without manual configuration in Tails. * Other transparent proxy types exist: There are also other types of transparent proxies such as content filtering, virus scanning, and so on. * {{project_name_short}} specific meaning: More complex, specific to {{project_name_short}}:
An application can use TCP/DNS [UDP blocked] over Tor (user -> Tor -> destination) without requiring additional configuration.
{{project_name_short}} specific: * Enabled by default: {{project_name_short}} has the 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. * {{project_name_gateway_short}} acts as a Tor Transparent Proxy: In other words, {{project_name_gateway_short}} by default can be used as a Tor Transparent Proxy. Connections from {{project_name_workstation_long}} to {{project_name_gateway_short}} are transparently proxied through Tor. * Example application: For example if using [[Telegram]] in {{project_name_short}}: Uses transparent proxying because it is not pre-configured by default to use Tor proxy settings. === Identity Correlation through Tor Circuit Sharing === * Risk from circuit sharing: If the user installs custom applications and omits explicitly taking precautions against {{Code2|identity correlation through Tor circuit sharing}}, the user is risking that different activities, let's say web (Chromium or similar) or IRC ([[HexChat]] or similar) go through the same Tor circuit and Tor exit relay. * What an observer can still correlate: 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 maybe the the Tor exit relay's {{isp}}) can potentially correlate those activities from different applications to the same pseudonym. * SocksPort vs TransPort behavior: The following graphic illustrates the difference of using Tor SocksPorts compared to using Tor's TransPort. ** Dedicated SocksPort per application: Using a dedicated Tor SocksPort per application results in taking different routes through the Tor network per application. ** Relay changes vary: Not necessarily all Tor relays (first, second, third) get replaced. Sometimes just the first, sometimes just the second, sometimes just the third, and sometimes multiple Tor relays in the Tor circuit change. * Different circuit does not guarantee different exit: Stream isolation does not necessarily result in using a different [[Tor Entry Guards|Tor Entry Guard]] or Tor exit relay. Therefore, a different Tor circuit can ''likely'' lead to using a different Tor exit relay and [[Data_Collection_Techniques#IP_Address|IP Address]], but this is not guaranteed. Related: [[Tips_on_Remaining_Anonymous#Only_Use_One_Online_Pseudonym_at_the_Same_Time|Only Use One Online Pseudonym at the Same Time]] '''Figure:''' ''Stream Isolation Illustration'' [[File:stream_isolation.1.0.jpg|Stream Isolation Illustration]] * {{project_name_short}} protection and why technical background knowledge helps: {{project_name_short}} implements protection against {{Code2|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. * How isolation is achieved: Different SocksPorts, DnsPorts, or TransPorts are routed through different Tor circuits, therefore preventing {{Code2|identity correlation}}. * Default application configuration: {{project_name_short}} configures most applications that come preinstalled with {{project_name_short}} to use a different SocksPort, thus no {{Code2|identity correlation}} is at risk. * How applications are directed to different SocksPorts: {{project_name_short}} uses either socks proxy settings to direct various applications to different SocksPorts or [https://github.com/{{project_name_short}}/uwt uwt] (more information below). * /etc/hosts and stream isolation: Applications configured for stream isolation (those using a SocksPort) ignore the /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#Tor_Browser_Transparent_Proxying|Tor Browser Transparent Proxying]]). Related: [[Tor_Browser/Advanced_Users#Tor_Browser_Filtering|Tor Browser Filtering]] * /etc/hosts and transparent proxying: Applications not configured for stream isolation, i.e. those using transparent proxying are usually honoring the /etc/hosts file. Select applications might have a specific implementation to ignore it depending on the application and unspecific to {{project_name_short}}. * Other traffic defaults: Any other traffic (i.e. custom installed applications, misc applications, such as nslookup, goes through Tor's DnsPort, and/or TransPort (can be optionally disabled, see below). == List == Related: * [[Dev/Default_Application_Policy|{{project_name_short}} Default Application Policy]] * [https://forums.whonix.org/t/should-strict-stream-isolation-by-a-requirement-in-whonixs-default-application-policy/3940 Should strict stream isolation by a requirement in Whonix's Default Application Policy?] Applications in {{project_name_short}} that are either prepared or fully pre-configured to prevent {{Code2|identity correlation through Tor circuit sharing}}: === By Settings === {| class="wikitable" |+ Stream Isolation - Settings Based |- !application !pre-installed !pre-configured !stream isolation by method !port !comments |- |[[Tor Browser]] |{{yes}} |{{yes}} |[[Tor_Browser/Advanced_Users#Proxy_Settings|socks proxy settings]] |9150 {{project_name_workstation_short}} 127.0.0.1:9150 gets redirected to 10.152.152.10:9150 by [https://github.com/Whonix/anon-ws-disable-stacked-tor anon-ws-disable-stacked-tor]. 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 the long run and also is simplest in case {{Code|update-torbrowser}} breaks and [[Tor_Browser/Manual_Download|manually updating Tor Browser]] is required again in future. | - |- |[[E-Mail|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]] |- |[https://www.kicksecure.com/wiki/Systemcheck systemcheck] |{{Yes}} |{{yes}} |socks proxy settings | 9110 | - |- |Bitcoin [[electrum]] Wallet (BTC) |{{Yes}} |{{no}} ([https://phabricator.whonix.org/T215 TODO]) |socks proxy settings |port prepared, IP 10.152.152.10, port 9111 | - |- |[[Monero]] (XMR) |{{yes}} |{{no}} ([[Monero#Stream_Isolation|TODO]]) |socks proxy settings | - | - |- |[[Tor_Browser#Tor_Browser_Downloader_by_{{project_name_short}}|Tor Browser Downloader by {{project_name_short}}]] |{{yes}} |{{yes}} |socks proxy settings |9115 | - |- |KDE application wide proxy settings |{{no}} |{{yes}} * https://github.com/Whonix/anon-apps-config/blob/master/etc/profile.d/50_anon-apps-config.sh * https://github.com/Whonix/anon-apps-config/blob/master/usr/share/anon-apps-config/kioslaverc |socks proxy settings |9122 no KDE applications with network activity pre-installed | - |- |} === By uwt wrapper === {| class="wikitable" |+ Stream Isolation - uwt wrapper based |- !application !pre-installed !pre-configured !stream isolation by method !port !comments |- |apt-get |style="background-color:{{Green}}"|yes |style="background-color:{{Green}}"|yes |uwt wrapper | - |[[Update]] |- |aptitude |style="background-color:{{Green}}"|yes |style="background-color:{{Green}}"|yes |uwt wrapper | - | - |- |gpg |style="background-color:{{Green}}"|yes |style="background-color:{{Green}}"|yes |uwt wrapper | - | - |- |ssh |style="background-color:{{Green}}"|yes |style="background-color:{{Green}}"|yes |uwt wrapper | - | - |- |git |style="background-color:{{Red}}"|no |style="background-color:{{Green}}"|yes |uwt wrapper | - | - |- |wget |style="background-color:{{Green}}"|yes |style="background-color:{{Green}}"|yes |uwt wrapper | - | - |- |curl |style="background-color:{{Green}}"|yes |style="background-color:{{Green}}"|yes |uwt wrapper | - | - |- |scurl |style="background-color:{{Green}}"|yes |style="background-color:{{Green}}"|yes |uwt wrapper | - |Uses curl, therefore same as curl. |- |} === none === {| class="wikitable" |+ Stream Isolation - none |- !application !pre-installed !pre-configured !stream isolation by method !port !instructions |- |GNOME application wide proxy settings |style="background-color:{{Red}}"|no |style="background-color:{{Red}}"|[[Dev/GNOME|no]] |style="background-color:{{Red}}"|none |no GNOME applications with network activity pre-installed | - |- |[https://www.kicksecure.com/wiki/Systemcheck systemcheck] --leak-tests |style="background-color:{{Green}}"|yes |style="background-color:{{Red}}"|no systemcheck --leak-tests runs only on user request and never by its own by chance. Tests two things, a Tor SocksPort and Tor's TransPort. SocksPort test uses SOCKS_PORT_SYSTEMCHECK 9110. Stream isolating transparent proxying, the Tor TransPort leak test is impossible. The whole point of the leak test is to check if connections not configured to use a Tor SocksPort will be torified or not. |style="background-color:{{Red}}"|none |See footnote. | - |- |} == Details == * How stream isolation is implemented: The required socks proxy settings are set up by various {{project_name_short}} configuration packages or uwt wrappers, which are set up on {{project_name_gateway_long}} and on {{project_name_workstation_short}}. * What uwt is: uwt is a wrapper around [https://gitlab.torproject.org/legacy/trac/-/wikis/doc/torsocks torsocks], which is also already installed to {{Code|/usr/bin/uwt}}. * How uwt wrappers behave by default: For example, each time you run a uwt wrapped application, i.e. simply type {{Code2|apt-get}} in console, the uwt wrapper {{Code|/usr/bin/apt-get}} will run. It adds uwt before apt-get. For curiosity, check {{Code|nano /usr/bin/apt-get}}. Essentially, the uwt wrapper then runs {{Code|/usr/bin/uwt /usr/bin/apt-get.anondist-orig}}. That is also the case for all other uwt wrapped applications. * How to bypass uwt when needed: If you ever want or need to run a uwt wrapped application without uwt, do not run for example {{Code|apt-get}} in console, instead run {{Code|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]]. * What bypassing uwt changes: When running {{Code2|/usr/bin/apt-get.anondist-orig}}, it directly goes through Tor's DnsPort and through Tor's TransPort and not through its own SocksPort. * Automatic localhost passthrough behavior: uwt checks whether the command contains the words {{Code2|localhost}} or {{Code2|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 IPs, isolate by destination address might help. * Isolate by destination port: This doesn't seem to be useful for anything in {{project_name_short}}. Applications using different protocols (and therefore different ports) are already isolated through using different SocksPorts. * Why it doesn't help for web browsing: Isolate by destination port doesn't really achieve anything for web browsing: [https://lists.torproject.org/pipermail/tor-talk/2012-May/024403.html tor-talk Tor's stream isolation features defaults]. * Where to learn more: For more information about stream isolation refer to the Tor manual. ** Stable manual: [https://2019.www.torproject.org/docs/tor-manual.html.en Tor stable manual] ** Alpha manual: [https://2019.www.torproject.org/docs/tor-manual-dev.html.en Tor alpha manual] === Tor Browser === * Domain-based SOCKS authentication: Tor Browser has a feature [https://gitlab.torproject.org/legacy/trac/-/issues/3455 Tor Browser should set SOCKS username for a request based on first party domain]. Tor Browser makes use of Tor's [[Stream_Isolation#IsolateSOCKSAuth|IsolateSOCKSAuth]] option. {{project_name_short}} does not break this feature. This feature does not even require Tor ControlPort access. All that Tor Browser requires from {{project_name_short}} is being able to connect to a Tor SocksPort. * Note about a previous claim: This wiki page stated Different tabs and websites in Tor Browser are isolated by Tor Browser. https://gitlab.torproject.org/legacy/trac/-/issues/3455 . This was either always incorrect or Tor Browser's behavior has changed meanwhile. {{quotation| quote='''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 [https://gitweb.torproject.org/torbutton.git/tree/src/components/domain-isolator.js 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. [https://bugzilla.mozilla.org/show_bug.cgi?id=1200802 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 [https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-52.5.2esr-7.0-2&id=8661822237c56d543d5c9117c8a4708c402a110f need to treat separately] or that [https://bugs.torproject.org/22343 lack a fix altogether]. |context=upstream, The Tor Project: [https://www.torproject.org/projects/torbrowser/design/ The Design and Implementation of the Tor Browser (DRAFT)] }} * Upstream is the source of truth: Tor Browser is developed by upstream, [https://www.torproject.org The Tor Project], which is an independent entity. For up-to-date information, refer to upstream, Tor Browser. * Related forum discussion: https://forums.whonix.org/t/tor-browser-new-identity-differs-from-restarting-tor-browser-in-whonix/3098/4 === Onion Services === * Automatic isolation for different onion services: Connections to different Tor [[Onion Services]] are automatically stream isolated. https://lists.torproject.org/pipermail/tor-talk/2012-September/025432.html == How to mitigate identity correlation == === Basic Protection === * Manually configure custom applications: If you install custom software on {{project_name_workstation_short}} that uses the internet, and you want to prevent {{Code2|identity correlation through Tor circuit sharing}} (which you should do), you have to manually configure it. This is not a {{project_name_short}} specific problem. If you used to use only one SocksPort with the [https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorifyHOWTO common torification methods], the [https://lists.torproject.org/pipermail/tor-talk/2012-March/023535.html same thing happened]. Read also [[Install Software|Software installation on {{project_name_workstation_short}}]]. * Use the pre-configured list where possible: A [[#list]] of applications that come pre-installed with {{project_name_short}} are pre-configured to prevent {{Code2|identity correlation through circuit sharing}}. * Be aware of TransPort pollution during tests: Traffic going through TransPort by default includes [https://www.kicksecure.com/wiki/Systemcheck systemcheck] when manually testing the TransPort by using systemcheck --leak-tests. If that is of concern to you, see the following bullets. * Optionally adjust systemcheck behavior: It can be disabled in systemcheck, see [https://www.kicksecure.com/wiki/Systemcheck_Hardening#Prevent_Polluting_TransPort prevent polluting TransPort], but that might make little sense. * Prefer to avoid the test instead: Better to avoid the test instead. * Understand the default routing: All custom installed applications' 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 {{Code2|identity correlation}} is at risk. What about UDP? See [[Tor#UDP]]. * Use a dedicated SocksPort per custom application: To protect against this, you have to set up and configure applications to use a dedicated Tor SocksPort. Each custom installed application has to be directed to a dedicated Tor SocksPort. For instructions how to do that, use the [https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorifyHOWTO 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 Workstations are automatically separated: [[Multiple Whonix-Workstation|Multiple {{project_name_workstation_short}}]] are automatically stream isolated. * No universal best method exists: What is better, configure the application's proxy settings or use 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 can be performed on how to torify applications. * This adds stream isolation on top of torification: Applications inside {{project_name_short}} are already torified but by applying these instructions inside {{project_name_short}} the user would go one step further, i.e. add stream isolation. * Up to date torification instructions are difficult to maintain: 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 whether the torification instructions are actually working. A leak would mean that portions of the application's traffic ignore proxy settings and/or circumvent the proxifier and are actually making external connections without using Tor. Such leaks would be much less severe in {{project_name_short}}. It would only result in {{Code2|identity correlation through Tor circuit sharing}} but not in a leak of the user's real IP address to the destination. * Support requests are usually ineffective: Asking for torification instructions for specific applications at {{project_name_short}} [[Support|Free Support]] is probably futile. The {{project_name_short}} is the wrong recipient for such support requests. One of the main reasons for the inception of the {{project_name_short}} 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 exact version that was being reviewed. Not to future versions of the application. * The legacy approach is less actively maintained: The legacy approach of torification of arbitrary applications on the host seems to have 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 torify specific applications and making sure these are leak free, users are probably told "use Whonix". * Honor protocol warnings: Protocol related warnings that you must honor still apply. You are still better off with {{project_name_short}}, as it offers best possible [[Protocol-Leak-Protection and Fingerprinting-Protection]]. * IP leak protection still applies: {{project_name_short}} setup provides protection against IP leaks through [https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorifyHOWTO#protocol-leaks protocol leaks]. * Misconfiguration has predictable outcomes: If you do not correctly torify, either no connections will be possible or traffic will continue going through Tor's TransPort unless you [[#Better Protection|disable transparent torification]]. * Do not share a SocksPort across applications: If you redirect more than one application to the same SocksPort, {{Code2|identity correlation}} is at risk. * DNS warnings still matter: DNS related [https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorFAQ#i-keep-seeing-these-warnings-about-socks-and-dns-and-information-leaks-should-i-worry warnings] still apply, though to a lesser extent. An attack could only make correlations but still could not figure out your IP. To prevent that, see chapter [[#Better Protection|better protection]]. * Avoid local DNS resolvers: Do not use a [https://gitlab.torproject.org/legacy/trac/-/wikis/doc/SupportPrograms#dns-resolvers local DNS resolver], as all DNS requests would be executed by the same Tor circuit. * Some leak classes do not apply here: Other leaks, such as applications not honoring the proxy settings / wrapper, ICMP or UDP leaks do not apply to {{project_name_short}}. * SafeSocks is optional: The SafeSocks setting is for rejecting unsafe variants of socks that might cause DNS leaks. The {{project_name_short}} 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. * Pre-prepared custom socks ports exist: On {{project_name_gateway_short}} there are already a lot of custom socks ports prepared for use with custom installed applications. Tor configuration file /etc/torrc.d/70_workstation.conf %includes file /usr/share/tor/tor-service-defaults-torrc.anondist. * Default range without isolation flags: Without {{Code2|IsolateDestAddr}} and without {{Code2|IsolateDestPort}}: SocksPort 9153 to 9159 * Range with destination address isolation: With {{Code2|IsolateDestAddr}}, but without {{Code2|IsolateDestPort}}: SocksPort 9160 to 9169 * Range with destination port isolation: Without {{Code2|IsolateDestAddr}}, but with {{Code2|IsolateDestPort}}: SocksPort: 9170 to 9179 * Range with both isolation flags: With {{Code2|IsolateDestAddr}} and with {{Code2|IsolateDestPort}}: SocksPort: 9180 to 9189 * Add more if needed: If those are not enough, you can add your own. * Isolation flags are usually unnecessary: What are {{Code2|IsolateDestAddr}} and {{Code2|IsolateDestPort}}? You can learn about them in the [https://2019.www.torproject.org/docs/tor-manual.html.en Tor manual]. See also [https://lists.torproject.org/pipermail/tor-talk/2012-May/024403.html tor-talk mailing list: Tor's stream isolation features defaults]. Usually, unless you know better, you are better off not using {{Code2|IsolateDestAddr}} or {{Code2|IsolateDestPort}}. {{Box|text= '''Generic instructions for configuring custom installed applications for stream isolation for less than 7 custom applications''' # [[Install Software|Install]] custom application. # Configure application to use a dedicated Tor SocksPort according to [https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorifyHOWTO Torify HOWTO] by either configuring the application's proxy settings or by using a proxifier such as torsocks. # Start custom application. }} {{Box|text= '''Generic instructions for configuring custom installed applications for stream isolation using proxifier (socksifier) torsocks''' # [[Install Software|Install]] custom application. # {{Open a product ws terminal}} 3. Start custom application from the command line by prepending torsocks. {{CodeSelect|code= torsocks application-name }} Using this method, there is no need to specify any proxy IP address, port number, protocol. This is because torsocks configuration file [https://github.com/{{project_name_short}}/uwt/blob/master/etc/tor/torsocks.conf.anondist /etc/tor/torsocks.conf.anondist] is preconfigured with setting IsolatePID 1. 
# Set Torsocks to use an automatically generated SOCKS5 username/password based
# on the process ID and current time, that makes the connections to Tor use a
# different circuit from other existing streams in Tor on a per-process basis.
# If set, the SOCKS5Username and SOCKS5Password options must not be set.
# (Default: 0)
IsolatePID 1
}} {{Box|text= '''Generic instructions for configuring custom installed applications for stream isolation for less than 7 custom applications using the application's proxy settings''' # [[Install Software|Install]] custom application. # Configure application to use a dedicated Tor SocksPort according to [https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorifyHOWTO Torify HOWTO] by either configuring the application's proxy settings. # protocol: socks 5 # Platform specific. Proxy IP: '''A)''' [[Non-Qubes-Whonix]] {{CodeSelect|code=10.152.152.10}} '''B)''' Qubes-Whonix: Use the IP address returned by running the following command (NOTE: do not use the command itself): {{CodeSelect|code=qubesdb-read /qubes-gateway}} # port: {{CodeSelect|code=9153}} (use a different port according to list above if using multiple custom installed applications) # 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 {{Code2|identity correlation}}: * Follow existing guidance: Read the advice above and on {{project_name_gateway_short}}. * Disable desktop-wide proxy settings: 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 are 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: 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|Multiple {{project_name_workstation_short}}]]. [[Multiple Whonix-Workstation|Multiple {{project_name_workstation_short}}]] using different internal IP's are automatically separated by Tor (IsolateClientAddr is Tor's default). === Disable Transparent Proxying === To deactivate transparent proxying, apply the following instructions. Following these steps will disable the {{project_name_gateway_short}} [[#Transparent Proxy|transparent proxying]] feature and transform {{project_name_gateway_short}} into an [https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorifyHOWTO/IsolatingProxy IsolatingProxy]. '''Note:''' The following instructions should be applied in {{project_name_gateway_short}} ([[Qubes|{{q_project_name_long}}]]: In App Qubes {{project_name_gateway_vm}}). '''1.''' {{Firewall_Settings}} '''2.''' Add. {{CodeSelect|code= WORKSTATION_TRANSPARENT_TCP=0 WORKSTATION_TRANSPARENT_DNS=0 }} '''3.''' Save. '''4.''' {{Reload_Firewall}} Although not strictly required, you could alternatively/additionally deactivate Tor TransPort and DnsPort. Add to {{Code2|/usr/local/etc/torrc.d/50_user.conf}}. {{Open /usr/local/etc/torrc.d/50_user.conf}} Add. {{CodeSelect|code= TransPort 0 DnsPort 0 }} Save. And then {{Reload_Tor}} '''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 DNS is disabled]] * [[#Check if Transparent TCP is disabled|Check if Transparent TCP is disabled]] === IsolateSOCKSAuth === See [https://2019.www.torproject.org/docs/tor-manual.html.en Tor manual] IsolateSOCKSAuth.
Don’t share circuits with streams for which different SOCKS authentication was provided. [...]
This 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 [[Dev/anon-ws-disable-stacked-tor|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 does not reach Tor on Whonix-Gateway. Hence, there is no benefit from IsolateClientAddr. [https://github.com/QubesOS/qubes-issues/issues/8398 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 not 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 it unless [[Reporting_Bugs#Contributions|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 an HTTP proxy, so maybe a Tor HTTPTunnelPort could be used. https://forums.whonix.org/t/tor-can-now-serve-as-http-proxy-httptunnelport/5373 ** Qubes-Whonix related: *** [https://github.com/QubesOS/qubes-issues/issues/7737 remove tinyproxy from Whonix-Gateway (sys-whonix) and make Whonix Templates networked by default with Net qube set to sys-whonix] *** [[Qubes/UpdatesProxy|Qubes-Whonix UpdatesProxy user documentation]] *** [[Dev/Qubes#Torified_UpdatesProxy|Torified UpdatesProxy developer documentation]] ** Future: Maybe in the future, after/if [https://github.com/QubesOS/qubes-issues/issues/9294 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)''' [[Stream_Isolation/Disable_Easy|How to disable stream isolation. The easiest and most 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 {{Code2|.anondist-orig}} to the command you want to run. For example, instead of using. {{CodeSelect|code= curl 38.229.72.22 }} Use. {{CodeSelect|code= curl.anondist-orig 38.229.72.22 }} ===== Environment Variable Method ===== Use the {{Code2|UWT_DEV_PASSTHROUGH}} environment variable. https://github.com/{{project_name_short}}/uwt/blob/master/usr/libexec/uwt/uwtwrapper#L194 Example. Set the UWT_DEV_PASSTHROUGH environment variable. This will disable using torsocks for all subsequent invocations. {{CodeSelect|code= export UWT_DEV_PASSTHROUGH="1" }} {{CodeSelect|code= curl 38.229.72.22 }} When running as user and using sudo, do not forget the sudo parameter -E which stands for preserve environment. {{CodeSelect|code= 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 ===== {{Uwt_wrappers_deactivate_all_permanently}} === Deactivate Misc Proxy Settings === {{Deactivate_Misc_Proxy_Settings}} === Tor Browser Remove Proxy Settings === If you would like to remove proxy settings from Tor Browser, see below. {{Tor_Browser_Remove_Proxy_Settings}} == Nested Execution == uwt version 4.0-1 and above protects from 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 {{project_name_short}} forums so perhaps a better fix for this can be found. {{Open with root rights|filename= /etc/uwt.d/50_user.conf }} Set uwtwrapper_max to a value more suitable for you. {{CodeSelect|code= uwtwrapper_max=100 }} Alternatively you could completely disable the nested execution protection. {{CodeSelect|code= nested_protection() { true } }} Save and exit. Done. == Development == === Information === See also the [https://2019.www.torproject.org/docs/tor-manual.html.en Tor manual] on SocksPort, HTTPTunnelPort, TransPort and DnsPort. ==== SocksPort ==== A SocksPort is a listen port by Tor which accepts traffic using the [https://en.wikipedia.org/wiki/SOCKS socks] protocol. Using a SocksPort is possible by using either: * [https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorifyHOWTO#Classicalcommonway:usetheapplicationsproxysettings application specific socks proxy settings] * [https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorifyHOWTO#classical-common-way-use-the-applications-proxy-settings wrapper method] such as torsocks (which can be automatically prepended using [https://github.com/{{project_name_short}}/uwt uwt]) Traffic on separate SocksPorts is stream isolated by Tor by default. ==== HTTPTunnelPort ==== A HTTPTunnelPort is a listen port by Tor which accepts traffic using the [https://en.wikipedia.org/wiki/HTTP_tunnel HTTP CONNECT method]. This is a new feature of Tor. Traffic on separate HTTPTunnelPorts is stream isolated by Tor by 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 [https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TransparentProxy TransparentProxy]. When using Transparent Proxying (default in {{project_name_short}}), all applications that do not use a SocksPort or HTTPTunnelPort will fall back to 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 [[Multiple Whonix-Workstation|separate {{project_name_workstation_short}}]]. ==== DnsPort ==== Similar to above but for DNS. All applications that do not use a SocksPort or HTTPTunnelPort will fall back to using Tor's DnsPort for DNS. ==== torsocks ==== All [[Stream_Isolation#By_uwt_wrapper|uwt wrapped applications]] will be stream isolated by [https://github.com/{{project_name_short}}/uwt/blob/master/etc/tor/torsocks.conf.anondist torsocks] /etc/tor/torsocks.conf setting IsolatePID 1. To test this, run the following command multiple times. 
scurl https://check.torproject.org | grep IP
=== Tests === 1. Applications which internally use curl. {{CodeSelect|code= sudo update-command-not-found }} {{CodeSelect|code= sudo update-flashplugin-nonfree --install --verbose }} 2. Applications which are uwt wrapped themselves and internally use ssh. {{CodeSelect|code= git push origin master }} 3. Enigmail. === Debugging / List of all uwt wrappers === {{CodeSelect|code= sudo dpkg-divert --list }} {{CodeSelect|code= ls -la /usr/bin/ssh }} === Deactivating an uwt wrapper === Example: {{CodeSelect|code= sudo unlink /usr/bin/ssh }} {{CodeSelect|code= sudo dpkg-divert --rename --remove /usr/bin/ssh }} === Check if Transparent DNS is disabled === '''Note:''' The following test should be performed in {{project_name_workstation_short}} ([[Qubes|{{q_project_name_short}}]]: App Qube {{project_name_workstation_vm}}). Test. {{CodeSelect|code= 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, then Transparent DNS is enabled. === Check if Transparent TCP is disabled === '''Note:''' The following test should be performed in {{project_name_workstation_short}} ([[Qubes|{{q_project_name_short}}]]: App Qube {{project_name_workstation_vm}}). Test. {{CodeSelect|code= {{Curl_Plain}} {{Check.torproject.org IP}} ; 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 performed in {{project_name_workstation_short}} ([[Qubes|{{q_project_name_short}}]]: App Qube {{project_name_workstation_vm}}). Test. {{CodeSelect|code= {{Curl_Plain}} 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 {{project_name_short}} 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 DNS is disabled]] * [[#Check if Transparent TCP is disabled|Check if Transparent TCP is disabled]] That is because it doesn't work without transparent proxying (system default networking), meaning if the application is unable to use the 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 * {{project_name_short}}: a stream isolation violation This is only a 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 * [https://github.com/rustybird/corridor corridor - Tor traffic whitelisting gateway] === Add new uwt wrapper === Emulate [https://github.com/{{project_name_short}}/uwt/commit/03cc4c8568564d5993fcc8ea975cf00e851f7052 this commit]. == Sources == * [https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/171-separate-streams.txt Separate streams across circuits by connection metadata] * [https://lists.torproject.org/pipermail/tor-talk/2012-March/023496.html tor-talk Operating system updates / software installation behind Tor Transparent Proxy] * [https://lists.torproject.org/pipermail/tor-talk/2012-March/023536.html tor-talk Awareness for identity correlation through circuit sharing is almost zero.] * [https://lists.torproject.org/pipermail/tor-talk/2012-May/024401.html tor-talk Tor's stream isolation features defaults Question] * [https://lists.torproject.org/pipermail/tor-talk/2012-May/024403.html tor-talk Tor's stream isolation features defaults Answer] * [https://web.archive.org/web/20141005211329/https://mailman.boum.org/pipermail/tails-dev/2012-August/001422.html Tails-dev separate Tor streams] * [https://tails.boum.org/todo/separate_Tor_streams/ Tails separate Tor streams] * [https://web.archive.org/web/20160629092058/https://mailman.boum.org/pipermail/tails-dev/2012-August/001532.html Tails-dev Please review Tails stream isolation plans] * [https://tails.boum.org/contribute/design/stream_isolation/ Tails Design: Tor stream isolation] Stream Isolation Graphic was contributed by: Cuan Knaggs, graphic and web design. [https://web.archive.org/web/20160313102442/http://revolver.za.net/ revolver] print media, web design, web development, CMS, e-commerce == References == {{reflist|close=1}} {{Footer}} [[Category:Documentation]] [[Category:Design]]