Hi We discussed the open questions yesterday and came up with the following:
Client-exit nodes should be considered like normal IP routers or to be precice like simple TCP bouncers. This means that the connection between a pseudo-exit node and a client-exit node needs no encryption and the fact that there are more people able to read the plain Alice-to-Bob traffic is nothing new. Every router on the way from the Tor exit to Bob already has this possibility. The same counts for the fact that Alice has no influence on which client-exit node is used which is true for any IP router as well. Last the client-exit does not debase anonymity. Just like no IP router or any other traffic relay is able to do so - given of course, Tor itself resists. The client-exit also does not add any anonymity for Alice. This means her circuit to the pseudo-exit must already be complete. Thus exitting over client-exit nodes means an extra latency of one TCP connection. The purpose of client-exit nodes is to give anonymity to the pseudo-exit nodes. This means it must be impossible to estimate the pseudo-exit when knowing the client-exit and that the client-exit node must choose its pseudo-exit uniformly distributed among all available Tor nodes. Concerning exit policies we think that propagating any client-exit information weakens the anonymity of the pseudo-exit node because it makes the client- to pseudo-exit link traceable. Furthermore client-exit nodes are very different from each other, so that we don't see how a pseudo-exit node could unify all client policies. So the only thing a pseudo-exit can say is: "well, there are some client-exit nodes connected to me." Generally client-exit circuits have drawbacks. Those are limited bandwidth, higher latency, low average and high variance for the uptime and unknown exit policies as we can not ask the personal firewall which outgoing ports are blocked. A reputation system for client-exit nodes could soften some of the drawbacks. But as far as we can see it would always weaken the anonymity of the pseudo-exit node because by the rules of the reputation system the possibility for a client-exit to pseudo-exit connection is not evenly distributed any more. But maybe it still would be impossible to reveal the pseudo-exit node. Do you have any suggestions on this? What is also still unclear is how the pseudo-exit node chooses from the available client-exit nodes. Perhaps it could select for each TCP connection of a circuit a different client-exit. Or it must try different client-exits until the TCP connection to Bob can be established. This would also soften some drawbacks. The idea of trying the next possibility until it works could be generalized by letting Alice open circuits until the pseudo-exit node has client-exit nodes attached to it. Thus the problem of information propagation at the directory servers are circumvented. On last thing is the question how a Tor node knows whether inbound traffic is meant to be normally relayed to the designated destination or whether it should be redirected through a client-exit node. To be honest we don't know all aspectes of the Tor protocols yet but as far as we know there already is a command protocol between Alice and Tor nodes. Is it possible for Alice to tell a node by this means to act as a pseudo-exit node? regards -- Alexander Bernauer
