_Originally created by Tails on [#5334 (Redmine)](https://public-redmine-archive.tails.boum.org/code/issues/5334)_ For release/1.0, we decided we want basic Tor stream isolation. {{toc}} # Roadmap We can start implementing and testing while we wait for [Tor 0.2.3](./Tor_0.2.3.html) to go into devel. Hopefully we get the whole thing in Tails 0.14 or 0.15. Implementation started in `feature/separate_Tor_streams`. done in Tails 0.14. # Design ## Tails-specific applications Tails-specific applications should use a dedicated `SocksPort`, so that they don’t help trivial correlating of other kinds of network traffic with Tails: - incremental updates - htpdate - security check - WhisperBack ## Web Browser See [separate Tor streams in the web browser](./separate_Tor_streams_in_the_web_browser.html). ## Destination address/port -based circuit isolation Do we want to use `IsolateDestAddr` and/or `IsolateDestPort`? Using these settings may help protecting against traffic correlation. However: - These settings are likely to have a performance impact on applications that connect to many remote hosts. - These settings probably put more load on the network. On the other hand, the Tor people probably are happy with people using it given they have added the option in the first place. We will anyway ask them to review our proposed configuration with network load in mind before we ship it to the masses. For performance reasons, we will start with *not* using `IsolateDestAddr`/@IsolateDestPort@ for iceweasel we ship: nowadays, loading a mere web page often requires fetching resources from a dozen or more remote sources. (Also, it looks like the use of `IsolateDestAddr` in a modern web browser may create very uncommon HTTP behaviour patterns, that could ease fingerprinting.) Consider Pidgin with several accounts configured for different identities. If you connect with all of the accounts at the same time, they’ll all get the same circuit, so the identities can be correlated. While Tails does not formally support using multiple contextual identities at the same time, Pidgin generally opens very few network connections, so the performance impact of using `IsolateDestAddr` should be small. Given how cheap it is, it looks like it is worth having Pidgin use a (not necessarily dedicated) `SocksPort` that has `IsolateDestAddr` and `IsolateDestPort` enabled. For the same reason, we actually want to enable `IsolateDestAddr` and `IsolateDestPort` for the `SocksPort` used by most applications, unless we tell them otherwise. The email client we ship is a special case: for the same multiple-accounts reason as the IM client, we want `IsolateDestAddr` for the MUA we ship. Adding `IsolateDestPort` to the mix would avoid correlating unrelated email and IM accounts, *but* it breaks POP-before-SMTP. Then, the MUA should use a `SocksPort` that has `IsolateDestAddr` enabled, but `IsolateDestPort` disabled. ## Conclusion This should be easy to implement, and enough to satisfy the "basic Tor stream isolation\" goal we have set for Tails 1.0: - default system-wide `SocksPort` (9050): `IsolateDestAddr` and `IsolateDestPort` enabled - dedicated `SocksPort` for the email client: `IsolateDestAddr` enabled - dedicated `SocksPort` for Tails-specific applications: `IsolateDestAddr` and `IsolateDestPort` enabled - dedicated `SocksPort` for web browser: no stream isolation options # Resources - [adrelanos’ email on tails-dev](https://mailman.boum.org/pipermail/tails-dev/2012-August/001422.html) - [aos design documentation](https://trac.torproject.org/projects/tor/wiki/doc/TorBOX/ApplicationWarningsAndNotes#Identitycorrelationthroughcircuitsharing) on this topic