separate Tor streams
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
andIsolateDestPort
enabled - dedicated
SocksPort
for the email client:IsolateDestAddr
enabled - dedicated
SocksPort
for Tails-specific applications:IsolateDestAddr
andIsolateDestPort
enabled - dedicated
SocksPort
for web browser: no stream isolation options
Resources
- adrelanos’ email on tails-dev
- aos design documentation on this topic
Original created by @tails on 5334 (Redmine)