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

[Jacob Appelbaum]

On 08/25/2010 02:12 PM, Robert Hogan wrote:
> So this is my take on the thread so far:
> 
> - We've zoned in on the fact that this proposal is really about isolating 
> applications on circuits rather than ports on circuits.
> 

I think so too.

> - Isolating by destination address is likely to increase the number of 
> circuits the client builds by some scary quantity.

I'm not sure that I'm entirely on board with that - I think for
webbrowsing this is true but for ssh or other traffic, I'm not sure. I
actually want five circuits when I start my Tor - one for IRC, one for
ssh, one for ttdnsd, one for email stuff, another for jabber and so on.
In most cases, I require a different circuit for each because I don't
want to link _any_ of that data.

I'm going to use Tor like this because otherwise, I can't use the
Internet anonymously. It seems likely that this is a common use case for
a number of people. When we throw browsing into the mix, I'm not sure of
the best way to handle the circuit building.

Perhaps we should write a test to actually gather usage data? It would
allow us to know where we might build a new circuit and count the total
used in say, a day?

> 
> - There is a potential attack if we isolate by port number alone. A 
> malicious website could server resources over a variety of port numbers, 
> learn our exit nodes for each, and then presumably correlate our activity 
> on port 443/80 with our activity on any services we use that it happens to 
> provide on any of the other ports.
> 

This is a problem but it is only a problem with a single protocol and I
think at best, it takes a user right back to the point where we've
started. For all other protocols, we've improved the security of the users.

> - We can achieve some/a lot of the benefits sought by the proposal if we 
> isolate streams based on the information provided by the socks request 
> itself. The things people have suggested are:
>   1 Socks authentication info (username/pass)
>   2 Socks listener address/port
>   3 Socks protocol
>   4 Socks client IP
>   5 Info in /proc/pid/cmdline garnered from the client's port number
> 

I think 1-4 are solid. It also seems reasonable to look at the user
making the call if possible but as Nick pointed out, it seems hairy.

I'd also add the TransPort and the NATD port to the list - it may be
that a user is transparently routed or NAT'ed into Tor. We should
account for them as well.

> My own view is that 1 to 4 above could be used to determine the choice of 
> circuit even in the absence of an IsolateStreamsBy* option. 5 is ugly and 
> generally won't work if running as a 'tor' user so can be discarded.
> 

I think it's probably true but I wonder about this on Windows or other
platforms?

> I think the only argument for making item 1 optional would be so that 
> people know about it. Maybe it can be an option and on by default. 

I think it should be on by default and I'm fine with it being always on.

All the best,
Jacob