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

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
• aos design documentation on this topic