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

[Jacob Appelbaum]

On 08/07/2010 05:10 PM, Nick Mathewson wrote:
> On Fri, Jul 23, 2010 at 11:03 AM, Jacob Appelbaum <jacob at appelbaum.net> 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.
> 

Good point, I've updated the proposal to fix the terminology.

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

I agree. I've added this to the proposal - nearly word for word.

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

I agree. I say that we "do it" but I'm not sure how to reword this -
thoughts?

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

That's a great idea. I've added it to the proposal.

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

I think that probably use both but fail closed; specifically, it seems
to be a good idea to not allow a local application to try to discover
circuits created by another application. I worry that a local
application may try to connect to say, an upstream webserver with local
username 'pidgin' and no password. What happens? I think without a
proper password, we should allow them through but not link the circuits...

Thoughts?

All the best,
Jacob