On 5/27/15, Allen <[email protected]> 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 - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
