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

[Mansour Moufid]

On Sat, Aug 7, 2010 at 8:10 PM, Nick Mathewson <nickm at freehaven.net> wrote:
> 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.

Whatever information is gained from such an attack would be no more
than what can be known currently, except that separate circuits would
mean the attacker has to then control many more exit nodes to get the
same information. So in the worst case scenario the user isn't any
more exposed than they already are. This assumes circuits do not share
exit nodes...

> 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 think no two circuits should use the same exit node, because doing
otherwise would defeat the purpose of the proposal.

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

Why not take this idea further: "IsolateStreamsBySOCKSFields" -- a
list of one or more keywords {"username", "password", "destination
address", "port number"}. Their values in the actual SOCKS fields
would be hashed together, along with a nonce, and each unique outcome
assigned to a circuit (not necessarily one-to-one). The nonce could be
changed every, say, 10 minutes.

That way, application that are SOCKS unaware would all be assigned the
same "default" circuit (similar to the current behaviour). If
'username' is in the list, then applications that want separate
circuits from other applications could set the username field. If
'password' is also in the list, applications that want multiple unique
circuits could set both the username and password fields, e.g. your
browser uses one password for DNS, another for 80, yet another for
443.

If only 'destination address' or 'port number' (or both) are listed,
then this emulates the behaviour of IsolateStreamsBy{Host,Port}.

Users that didn't want to support any of this could just leave
IsolateStreamsBySOCKSFields empty (in which case only the nonce
matters).

Seems like a compromise. :)

-- 
Mansour Moufid