Re: [tor-talk] Awareness for identity correlation through circuit sharing is almost zero.

[grarpamp <grarpamp@xxxxxxxxx>]

Does this ask for using a pre existing load balancer solution?

Can the host's firewall be configured to fan out (say round robin
or flow based) the streams (and dns) that it would normally capture
and send to a single TransPort and DNSPort... across multiple Tor's
providing same access ports?

I hesitate to accept the suggestion that torsocks (the preloadable
library) be suitably adapted to fan out to multiple SocksPorts.
Because some applications don't work with it, such as those that
have been statically compiled for other reasons. And well, torsocks
is a curious hack to begin with.

Some balancers can send certain fractions of the traffic to different
locations based on administrative maps. 0-9a-f here, g-q there, r-z
wherever. Flows are turned into hashes, hashes are routed.

Though only a single Tor instance with 'stream isolation' could
guarantee the use of separate exits. And of course only up to the
current number of exits before parallel use is required.


> Stream isolation is one of the big features in Tor 0.2.3.x, but
> it's a bit hard to figure out how to use it up most effectively.
> This is something I hope people can help come up with good ideas
> and documentation for.

You mean maybe try flow based isolation? ie: pairing src/dst/tcp/udp/port
as a blob that needs separated. Also include .onion as a dst.

Someone implied websurfing by mentioning referrer's. Ignoring the
src port in the flow would help a user stay with one exit for the
normal 10min timeout. TrackHostsExits would extend that as usual.

A busy client often has hundreds of circuits in BUILT state with a
handful new circuits per second and tens new destinations per second.
I don't know how the exits are distributed among those circuits.
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk