Re: [tor-talk] isolating multiple server requests

[coderman <coderman@xxxxxxxxx>]

On 5/27/15, Allen <allenpmd@xxxxxxxxx> wrote:
> I have a client application that Tor to communicate with several servers.
> For privacy reasons, it is important that after each request, the client
> starts with a "fresh slate" so the server is not able to tell that the next
> request is coming from the same client.

ok, this is "stream isolation" and supported, as you discuss.



> 1. The client can make a new connection to the Tor proxy with a new unique
> username, see
> https://gitweb.torproject.org/torspec.git/tree/socks-extensions.txt.  My
> concern here is that over time, the Tor proxy will build up a long list of
> prior usernames that are never going to be used again.

you can expire out oldest, but i don't think you'll find this a
problem in practice.



> 2. The client can send Tor proxy a NEWNYM signal on its control port.

right; this is a big hammer - more than just isolation, although it
can be used to enforce isolation forward.


>  My concerns here are that:
> a. The spec implies Tor proxy might ignore that signal, see
> https://gitweb.torproject.org/torspec.git/tree/control-spec.txt

you can use stem to manually control / cull circuits and streams, too.
a back-up plan, perhaps.



> b. It is not clear to me how to be certain when the request has completed
> and it is safe to attempt a new connection.

right - you'd need to look at actual circuits via control port to know
for certain in all circumstances.



> c. That would reset circuits to all servers, including some circuits that
> might be in use.  While I don't think that would result in an error, it
> would slow down those requests and make Tor do unnecessary work to
> reestablish circuits.

right; also trade-off's involved.



> 3. The client can somehow talk directly to the Tor controller to establish
> new circuits.  My concern here is the complexity and potential to make a
> programming mistake that leads to information disclosure.

some Tor control port consumers restrict to only a few necessary
commands - thus eliminating the truly ugly and trivial attacks against
your anonymity using the control port against you.

stem is a nice python interface to do what you want. it is adding
complexity, but implemented thoughtfully the benefit would outweigh
risk.



> What is the best approach in this situation?

see also options:
IsolateClientAddr, IsolateSOCKSAuth, IsolateClientProtocol,
IsolateDestPort, IsolateDestAddr, etc.

note that potentially only on by default are: IsolateClientAddr,
IsolateSOCKSAuth

there is also a trac,
 #16004: Support Isolation by SCM_CREDENTIALS / SCM_CREDS for AF_UNIX
endpoints - https://bugs.torproject.org/16004 which may be relevant to
you.


best regards,
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk