Re: Proposal: Separate streams across circuits by destination port or destination host

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Fri, Jul 23, 2010 at 11:03 AM, Jacob Appelbaum <jacob@xxxxxxxxxxxxx> wrote:
> Hello,
>
> Nick blessed me as a co-proposal editor last night at PETS2010; I've
> given the following proposal an initial number of 171.
>
> The proposal in question will be updated in my git repository until it
> is accepted into master:
> https://gitweb.torproject.org/ioerror/tor.git/blob/refs/heads/isolated-streams:/doc/spec/proposals/171-separate-streams-by-port-or-host.txt
>
> Here's the proposal in question:
>
> Filename: 171-separate-streams-by-port-or-host.txt
> Title: Separate streams across circuits by destination port or
> destination host
> Author: Robert Hogan, Jacob Appelbaum, Damon McCoy
> Created: 21-Oct-2008
> Modified: 22-Jul-2010
> Status: Draft
>

Hi, Jacob, and sorry about the delay in getting to this.  I think I've
figured out a way to enhance this proposal and make it even more
secure.

Preliminary notes:

A. You should consistently say "streams" or "application connections"
not "connections".  In Tor specification vocab, we tried to reserve
"connection" for an arbitrary TCP connection (including OR
connections) and "stream" for the kind of connection-like thing that
gets relayed end-to-end.

B. There's an attack we talked about at PETS where a hostile web page
possibly in collusion with an exit node contains image links for
images at (say) "evil.example.com:53" and "evil.example.com:31337",
and thereby (if they're lucky) correlate port-80 circuits with port-53
and port-31337 circuits.  This isn't a total showstopper, but it needs
to be analyzed.

C. This part needs clarification IMO:

> Implementation notes:
>
> The implementation of this option may want to consider cases where the
> same exit node is shared by two or more circuits and
> IsolateStreamsByPort is in force. Since the purpose of the option is to
> reduce the opportunity of Exit Nodes to attack traffic from the same
> source on multiple ports, the implementation may need to ensure that
> circuits reserved for the exclusive use of given ports do not share the
> same exit node.

There is too much "we may want to X" here for now.  We should figure
out the answer to whether isolated circuits should force distinct exit
nodes or not, and either say "do it" or "don't do it".  If we can't
answer this in the spec, it's pretty hopeless to ask users or
implementors to decide it for us in the future.

D. Allow me to propose a third way to isolate streams that will enable
even smarter application-level isolation without requiring any code
changes to most applications:

** IsolateBySOCKSUser -- If this boolean option is true, then Tor will
look at the username field of the SOCKS protocol, and make sure that
any two streams that were created with different SOCKS usernames will
be sent over different circuits.  The empty username will be treated
as its own username different from all other usernames.

Assuming an application with complete socks support (or an application
using a proxy with complete socks support, etc), the application can
use this to isolate all of its connections regardless of port.  If you
want to isolate your IM connections from your firefox connections from
your ttdnsd connections, all you need to do is tell each application a
different socks username in its configuration.  You could have two
connections to the same host on the same port always use different
circuits simply by setting up a socat connection for each one that
always used .

An application (or application plugin) that was aware of this feature
could even use it to signal which streams are inherently linkable, and
which streams should remain unlinkable.

This feature would incidentally make the attack in B unfeasible.

One thing I'm not sure of: should it look at socks user only, or
should it look at user+password combination?

yrs,
-- 
Nick