Re: Iran + tor
Hi I always wondered how Tor can help circumventing censorship. If I were a dictator I would force the ISPs to block access to the directory servers. If that's not enough one can retreive the list of all Tor nodes and block them. Can anyone explain me what I am missing? regards Alex signature.asc Description: This is a digitally signed message part.
Re: Paid performance-tor option?
On Tue, Aug 19, 2008 at 06:30:35AM -0500, Scott Bennett wrote: > OTOH, failure to edit responses properly simply makes comprehension > of the sequence of messages very difficult. Keeping track of who said > what when text from previous messages is quoted without attribution is > like trying to read a story with some or all of the characters' names > removed, especially when there are lengthy conversations in the story. What you do forget is, that it does not help to know who said something if you don't know when he said so. Therefore all your arguments above apply to failure in setting the right mail headers as well. Your mail attitude really prevents people from reading this list productively. You say we concern about content? Then please don't be an encumbrance to us to do so. regards -- Alexander Bernauer
Re: getting more exit nodes
On Wed, Apr 23, 2008 at 07:51:51AM -0700, Martin Fick wrote: > I really don't understand why pseudo-exit node > anonymity is so important? The short answer: Admins who run a Tor node which is for good reasons not an exit node should be able to run at least a pseudo-exit node without additional personal risk. The long answer: As anonymity grows with the number of participants we intented to persuade all tor node admins to run a pseudo-exit node as well. But if it is possible to estimate the pseudo-exit node when knowing the client-exit node legal enforcement might start to pursuit those nodes just like normal exit nodes, too. As the past showed even in "constitutional states" this results in tor nodes going down forever. And depending on the (il)legal system you live in the possibility alone could be enough reason for you to not run a pseudo-exit node. > The client-exit nodes will end up being filtered instead. As there is no global listing of client-exit nodes you can not distinguish whether the traffic to your server comes from the apparent IP node or whether it originates from the Tor network. So we think blocking client-exit nodes is not feasible. cu -- Alexander Bernauer
Re: getting more exit nodes
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
Re: getting more exit nodes
On Sun, Apr 20, 2008 at 01:03:21PM +0100, Michael Rogers wrote: > Are you sure it's a good idea to encourage non-technical users, who > might not understand the legal risks, to run exit nodes? I don't see how we can establish an anonymous transport system without risk dispersing. If there are enough participants the individual risk becomes small. Compared to the risk to which many users already are exposed because theire computer is hacked and serves in a bot net this additional risk should be small. But we don't want to trick anybody. The risks will be explained and the user is free to choose. cu -- Alexander Bernauer
Re: getting more exit nodes
Hi On Sun, Apr 20, 2008 at 02:47:34PM +0200, Sebastian Hahn wrote: > Please note how long it takes for a Tor node to be used by clients, How long is that? Are there any statistics about that? > I think this will produce a huge amount of overhead when > such nodes are sending their descriptors and others will try to use > them a few hours later, when they have been shut down again. This problem exists as soon as end-user's computers become Tor nodes. How is this solved currently? Are all Tor nodes servers with high uptimes? > They don't want a plugin that does arbitrary things they don't > quite understand. We will see. We don't insist on having a browser plugin. > If you find a good solution for how to make use of Tor relays behind > restrictive firewalls, that'd be most awesome, but I think such an > approach should be included in the Tor software. Well, until now I think my proposed solution could work. > Note that currently, any relay must be able to connect to any other > relay. Client-exit nodes are no normal relays. They have no incoming connections. They are simply the log scapegoats for the pseudo-exit nodes. cu -- Alexander Bernauer
getting more exit nodes
Hi The CCC local group Rheintal [1] is currently working on a solution to get much more Tor exit nodes which we think is a major problem of Tor. The basic idea is to develop a browser plugin which while active turns the computer into both an Tor client and a Tor exit node. The target group is a Windows XP or Vista user with almost no technical skills but fear of pop-ups asking strange things. We are experienced in providing and promoting security software to them [2] and we beliefe that this solution will be accepted and widely used. To get the software done I would like to discuss the technical aspects here. The bigest problem we see are those personal firewalls which prevent running a normal Tor server. Therefore this machine needs to open a client connection. That's why we call it a client-exit node. So we need some servers for the client-exit nodes. This nodes we call pseudo-exit nodes. The reason for this is that Alice selects this node as exit node for its circuit but the traffic gets routed to the client-exit node. So the pseudo-exit node doesn't appear in the server logs. This means that every Tor node can become a pseudo-exit node without any additional law enforcement risks. Given that all Tor nodes are pseudo-exit nodes a client-exit node would select a Tor node at random and connect to it. As soon as a pseudo-exit node has at least one connection to a client-exit node it registers itself at the directory server as a normal exit node. From now on everything goes the normal way except that the pseudo exit nodes passes the traffic which would normally go out of the Tor network to the client-exit node. This is the basic idea. I'm sure there are technical aspects we missed or assumptions which are wrong. So I would appreciate if you could point us on them. We tried hard to find a solution which would not require patching existing Tor nodes. But we didn't find any. Maybe we do in this discussion. [1] http://ulm.ccc.de/Rheintal [2] http://www.dingens.org regards -- Alexander Bernauer
