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

Nick Mathewson nickm at freehaven.net
Thu Aug 26 18:44:32 UTC 2010


On Wed, Aug 25, 2010 at 5:12 PM, Robert Hogan <robert at roberthogan.net> 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.
>
> - Isolating by destination address is likely to increase the number of
> circuits the client builds by some scary quantity.
>
> - 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.
>
> - 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
>
> 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 tend to agree wrt 1..4.

5 is not only ugly but also hard and unportable.  I spent a lovely
evening a couple of weeks back reading the sources to "lsof" to see
how they answer the "what process is using this socket" question, and
the games that lsof needs to play are fiddly, platform-specific, and
sometimes grossly inefficient.  My hat is off to the lsof authors and
maintainers, but we do not want to try to do what they do.

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

Personally, I think it's fine to have all of 1..4 on-by-default and
maybe even "always on".  I am having a hard time thinking of a use
case where somebody is using socks username/password or multiple socks
listeners or multiple socks protocols or connecting from multiple
client IPs and where they would _want_ the streams from these
different socks usage profiles coalesced into different circuits
together.

-- 
Nick



More information about the tor-dev mailing list