[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tor-talk] isolating multiple server requests
On 5/27/15, Allen <email@example.com> 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
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
> 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,
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
tor-talk mailing list - firstname.lastname@example.org
To unsubscribe or change other settings go to