[tor-talk] SocksPort: Circuit isolation is not Exit isolation

[grarpamp]

Update: My nutty fruit bat now tells me I had 'trackhostexits .'
turned on in the original example. I think that explains the growth
of the matching exit (4th node) onto the second circuit.

Without that I get (with SessionGroup as default)...

r1 r2 r3
r4 r5 r6

r1 r2 r3
r4 r1 r5

r1 r2 r3
r1 r4 r5

r1 r2 r5  I wasn't able to reproduce another 'same exits' case
r3 r4 r5   during the test period.

So two calls to the same <dest_ip:port> over different socksport
do not traverse the same identical node path from entry to exit.
But some partial relay or exit reuse is possible. Maybe even up to
reusing all the same relays but in a different order?

The man page speaks of streams (TCP) sharing circuits. Not sure if
there can be multiple circuits using the same relay path (ATM VC's),
or if each path carries just its own circuit or stream. Isn't there
some artwork somewhere on Torproject? I'll look for it.


It would be nice to have trackhostexits optional per socksport.
And to have newnym and mapaddress applicable per port. The idea
being to have one daemon serve most needs.
 https://trac.torproject.org/projects/tor/ticket/6883


Regarding exit isolation across socks ports (ExitSessionGroup?)...

>>> The typical use case is wanting to use multiple accounts on the
>>> same site at once, with a guarantee that you're not appearing to
>>> be from the same exit and thus are not as easily linked.

Before digressing into valid yet tangential stats theory, this was
the problem statement at hand. And currently, using multiple Tor's
(whether mapaddressed or even just left to drift) seems to be the
best available way to do that.

> http://freehaven.net/anonbib/papers/pets2011/p1-perito.pdf

This paper is readable. The usernames I was thinking of (but not
described in this thread) would not match their classifier but might
trigger a human classifier.

> The casual log observer will see that all three have, at some
> time, connected from IP addresses whose reverse-DNS strings contain
> "tor", and decide based on that that they are all the same person.

Given the estimated 450k Tor users all accessing whatever their
sites of the day are, the simple use of Tor alone will likely not
yield that conclusion.

It just seems like a useful option for users wishing to manage that
part of their own known usage pattern. Anyways.