Re: A way to allow firewalled exit nodes [Was: Re: getting more exit nodes]
F. Fox wrote: I think that adding a firewall-piercing rendezvous-type system (like STUN, or I2P's SSU) to allow heavily-firewalled nodes to act as exits - ON A STRICTLY VOLUNTARY BASIS (i.e., off by default) - might be a nice feature. Maybe Tor could copy Gnutella's connection reversal trick: if a node X is firewalled, it connects to any unfirewalled node Y and publishes Y's address in its descriptor. When an unfirewalled node Z wants to open a connection to X, it sends a message to X through Y, and X opens a connection back to Z. The X-Z connection is used exactly as if it were a Z-X connection established in the normal way. The circuit doesn't pass through Y, so all the crypto from TLS upwards remains the same. Your comments about modifying the descriptors would still apply, though, and clients would have to be aware of it because connection reversal can't establish a connection between two firewalled nodes, so no circuit could contain two consecutive firewalled nodes (I guess that might have implications for anonymity as well). But if it allows more people to run nodes then maybe it's a worthwhile tradeoff? Cheers, Michael
Re: A way to allow firewalled exit nodes [Was: Re: getting more exit nodes]
On Tue, 29 Apr 2008 14:50:15 +0100 Michael Rogers [EMAIL PROTECTED] wrote: F. Fox wrote: I think that adding a firewall-piercing rendezvous-type system (like STUN, or I2P's SSU) to allow heavily-firewalled nodes to act as exits - ON A STRICTLY VOLUNTARY BASIS (i.e., off by default) - might be a nice feature. Maybe Tor could copy Gnutella's connection reversal trick: if a node X is firewalled, it connects to any unfirewalled node Y and publishes Y's address in its descriptor. When an unfirewalled node Z wants to open a connection to X, it sends a message to X through Y, and X opens a connection back to Z. The X-Z connection is used exactly as if it were a Z-X connection established in the normal way. The circuit doesn't pass through Y, so all the crypto from TLS upwards remains the same. Your comments about modifying the descriptors would still apply, though, and clients would have to be aware of it because connection reversal can't establish a connection between two firewalled nodes, so no circuit could contain two consecutive firewalled nodes (I guess that might have implications for anonymity as well). But if it allows more people to run nodes then maybe it's a worthwhile tradeoff? Looks good to me. And it eliminates the need for non-firewalled servers to keep a separate, local directory of directly connected servers like I was proposing, and that is very much better, IMHO. I don't see any real threat to anonymity along the line that you mention. The specially marked descriptors would represent *additional* servers to the pool of existing servers to choose from in selecting a route. I agree that initially there might be a small risk involved when the first few such firewalled servers appear on-line, but once the numbers increase, that problem goes away. When tor first came into use, the number of exit servers must have been very small at first, but there are so many now that the use of a minority fraction of the total server count is not a significant risk factor. It looks to me as though we may have a design embryo already. Perhaps Roger and Nick could comment and give their thoughts on what else may be needed for it. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * **
Re: getting more exit nodes
On Sunday 27 April 2008 21:57:34 F. Fox wrote: Alexander Bernauer wrote: 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. (snip) This is why I've got reject *.* - I feel that the level of risk is just too much for me, given the current state of things. That being said... I just don't understand this pseudo-exit thing, and could really use a clear set of documents (or better yet, something with diagrams), so I can get my brain around it. Basically: 1.) How can someone be an exit, without letting arbitrary users take on the identity of their IP? As soon as someone does that (as is with normal exits), they're open to crapstorms from anything bad anyone does... and I just don't understand how that can be avoided. 2.) If a pseudo-exit doesn't loan out its IP, it must be hiding it somehow - most likely through another proxy. How on Earth can that be an exit? Sorry, but I've just been confused from the beginning. Let's say I'm a client-exit and you're a pseudo-exit. This is how it works: 1. I boot up tor and start using it as a client. I also connect to your middleman and tell you that you can send anything you get my way. 2. You advertise yourself as a pseudo-exit in addition to being a middleman. 3. Other Tor clients select their client paths as normal and sometimes select your middleman as their exit. 4. When you receive such client traffic you immediately forward it to me. 5. I take it from you and forward the traffic to the real internet, as though it's coming from me. I route everything I get back to you. So this means: 1. I'm not a real exit and neither are you. 2. I'm your only gateway out of the Tor network. 3. Given that the connection between us is encrypted, nothing is leaving your box in the clear as it would if you were a real exit. 4. The relationship between the traffic that passes between us and what I pass on to the real internet would be fairly trivial to establish. 5. You are definitely not the garbage-in, garbage-out middleman you once were, since you can actually see what you're passing on to me. Thiis would be the red-light for most confirmed middlemen. 6. I'm not quite sure what I am, and I'm not sure I'd like to be me by default - especially since by definition under this scheme I'm a home user who is not even a listed tor node. I would not be happy if I was using Tor to post anonymously to a forum for a sensitive disease only to find my computer was requesting rather more sensitive pictures of ladies' ankles (in Nick's immortal phrase) without my knowledge . signature.asc Description: This is a digitally signed message part.
Re: getting more exit nodes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Alexander Bernauer wrote: 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. (snip) This is why I've got reject *.* - I feel that the level of risk is just too much for me, given the current state of things. That being said... I just don't understand this pseudo-exit thing, and could really use a clear set of documents (or better yet, something with diagrams), so I can get my brain around it. Basically: 1.) How can someone be an exit, without letting arbitrary users take on the identity of their IP? As soon as someone does that (as is with normal exits), they're open to crapstorms from anything bad anyone does... and I just don't understand how that can be avoided. 2.) If a pseudo-exit doesn't loan out its IP, it must be hiding it somehow - most likely through another proxy. How on Earth can that be an exit? Sorry, but I've just been confused from the beginning. - -- F. Fox AAS, CompTIA A+/Network+/Security+ Owner of Tor node kitsune http://fenrisfox.livejournal.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSBTovuj8TXmm2ggwAQjlBBAAmUaXOR778ntn77PB2FoNQ9fWRggreYLx iCr1Og4KINx1JRKzMDSLJFUmHbivzTIpGOHcjSC7VvECOUuBN8qKAfaF8GYKcNRx Yh5lvR8nYfgU5fLHDWowJKwqkiOgSD4tDGfmKKl8qsgyP+OISCOsE+DIipugsLqQ +/Z3a+j7QyQKJPy0hLNtyMaMCfncwyEs/iVPep//89TipqQVYn4/bOf2HVwJztvp /+9P1DIRIOg/uge0Y4fM+kz7GW8S7ETNgcUQAYFkTz5p1HJuplVx42liGqt5J4Cx Vdc3iEkN4qerOmBkCHGfuSlkocrhwcoUC0h3M+Wl8fNXgHZbJGn0givqgc5Lh+Fl 22niqjPia0b8Chem7fHBz4Aak+d1JXm2JVepe1In5Rj7r7ECsAwtnl7A9suvPzXk YK9M9oP/pF1PL9hG2yIKjZAbxB5SV82CdsQETGByRR7iRGsLOyWn6mlhiPsptUc1 xWmnOKuK06rRTEO0mzvZ/otoPDF8GZTQ0yGzEGp8i0AcimBlLo+3+2u4XTZZ4yBp UM4KBrdOVFS5xe39m7tOG4FuqSTNVZ8oNkfyBbWLXrQlKwVKE5on4BqX3wWMHYJO Gtjk1Xzwl+fo8BjphZrT5LKoXs6S/gqwEoKdRjrgjYj5O6DDBQQEQYx4aZge/WhH YFQcnYdxcJY= =Z8Fc -END PGP SIGNATURE-
Re: getting more exit nodes
On Sun, 27 Apr 2008 13:57:34 -0700 F. Fox [EMAIL PROTECTED] wrote: Alexander Bernauer wrote: 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. (snip) This is why I've got reject *.* - I feel that the level of risk is just too much for me, given the current state of things. I reject port 80, but let exits to hundreds of other ports through. That being said... I just don't understand this pseudo-exit thing, and could really use a clear set of documents (or better yet, something with diagrams), so I can get my brain around it. Basically: 1.) How can someone be an exit, without letting arbitrary users take on the identity of their IP? As soon as someone does that (as is with normal exits), they're open to crapstorms from anything bad anyone does... and I just don't understand how that can be avoided. 2.) If a pseudo-exit doesn't loan out its IP, it must be hiding it somehow - most likely through another proxy. How on Earth can that be an exit? Sorry, but I've just been confused from the beginning. I think the original proposal was, at least in part, an attempt to provide a way to effectively get more exit servers by allowing people to run exits who are unable to make an ORPort reachable due to firewall restrictions over which they have no authority. Their systems connect to registered servers and would then be able to offer exit service. (They could also offer relay service by the same token, but that's irrelevant here.) However, when connections to other servers are closed/broken, their services are no longer available via the same routes. The original proposal also included an involuntary draft of any non-server (in the registered sense) that connected to a registered server. It also failed to provide encryption for the final hop to the real exit, a serious failing that bothered many readers, and removed some control over route selection from the client and placed it instead with the pseudo-exit. My counterproposal is essentially to expand/enhance the existing communication between servers to allow would-be servers with insurmountable firewall restrictions to offer their exit capabilities to the various servers to which they connect. The listing of such services would be kept locally in those servers and deleted upon termination of the relevant connections. Clients' route selection and construction routines could request from an exit server (but in principle, could be any server) via fully encrypted paths the queried server's local directory of extra hops to such local exit servers. (N.B. that local simply means directly connected; i.e., local is used here in a topological sense, not a geographical one.) Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * **
Re: getting more exit nodes
On Fri, 25 Apr 2008 11:15:51 +0200 Alexander Bernauer [EMAIL PROTECTED] wrote: 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. Maybe I've forgotten something from early in the thread, but at the moment I'm a bit mystified as to why pseudo-exits are worth anything. They appear to be essentially just relay-only nodes, except with the destinationward side of each circuit being unencrypted and therefore less secure from an anonymity standpoint. Adding unencrypted hops would multiply the problems we already have with tampered exit nodes. If you want an extra hop in the circuits your client builds, you can make that change simply enough yourself, and that will give you circuits that are encrypted all the way to a genuine exit node. This whole pseudo-exit+client-exit stuff looks to me like it would take a lot of coding and would provide a negative benefit. Here's a more general idea. The protocol for overhead communication between servers and other servers and between clients and servers could be expanded. That way any running tor could negotiate with exit nodes to establish whether the former were willing to provide a limited exit service. This could be initiated by either side, but practically speaking, it might best be implemented such that it were always initiated by the same side. (My initial feeling here is that it would reduce overhead communication to have the negotiation always initiated by the node volunteering limited exit service.) If so, the exit node could add a descriptor for the former to a directory internal to itself. Clients building circuits to the exit node could then obtain from the exit node a small directory of those descriptors held locally by that exit node. It could then choose an additional hop to one of those volunteer limited exits or stick with the original exit node. If the connection between the original exit and the volunteer limited exit were broken or closed by either side, the exit could send a message along all open circuits that were using the limited exit back to the originating clients to inform them of the change, so that the clients could decide what to do next. The exit server would, of course, immediately delete the descriptor for the lost limited exit node from its local directory of currently connected limited exits. This obviously would also take a lot of work, but Roger, Nick, et al. have already demonstrated their ability to map out the required protocol designs for what they have produced already. I'm very confident that they could also come up with a next generation, generalized operational communications protocol for tor instances to use with each other that would include the capabilities of the more restricted communication protocol already in use within the tor network. Such a method would preserve intact the tor philosophy and security and would merely add a highly flexible facility to enhance the existing capability for automated reconfiguration of the tor network. It also would solve the problem of how to offer exit service from behind a firewall to which the tor operator has no power to add RDR rules to pass packets to the ORPort because the packets from the original exit node would simply travel along the connection established by that particular limited exit node. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January
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
--- Alexander Bernauer [EMAIL PROTECTED] wrote: The purpose of client-exit nodes is to give anonymity to the pseudo-exit 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. ... But as far as we can see it would always weaken the anonymity of the pseudo-exit node ... I really don't understand why pseudo-exit node anonymity is so important? The only thing that you are trying to do is remove the pseudo-exit node's IP from logs right, not to actually make it anonymous. In other words you are simply trying to make the pseudo-exit node less responsible for any abuses exiting it along with trying to prevent its IP from being filtered by web sites right? If so, simply making the client-exit node not log where it connected to should be enough right? Why try and hide the pseudo-exit node anymore than that, especially if it is not enhancing the anonymity of the tor user? After all, even if the pseudo-exit node were identified, it could not be statically filtered if it uses different client-exit nodes all the time right? The client-exit nodes will end up being filtered instead. What am I missing? -Martin Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: getting more exit nodes
Roger Dingledine schrieb: - Related to load balancing: how much additional latency are we talking about, from adding a fourth hop to the circuit? Because it would seem that you need four hops, since the relay to client-exit hop isn't adding much additional anonymity. (Or is it?) I believe this to be the most interesting question... since the user does not know his connection will be relayed via a client-exit, there will only be encryption up until the last relay (the one advertising itself as an exit). Therefore, even if you re-encrypt the data for transfer to the client-exit, it will now be *two* hops being able to read the user's traffic in cleartext. I don't think that's an improvement... I'd even go as far as saying it's the exact opposite of what we want. Plus, having the last relay re-encrypt the connection will add additional CPU and RAM load, which IMHO is not a good idea. Regards Andrew
Re: getting more exit nodes
--- Andrew [EMAIL PROTECTED] wrote: Roger Dingledine schrieb: adding much additional anonymity. (Or is it?) I believe this to be the most interesting question... since the user does not know his connection will be relayed via a client-exit, there will only be encryption up until the last relay (the one advertising itself as an exit). Therefore, even if you re-encrypt the data for transfer to the client-exit, it will now be *two* hops being able to read the user's traffic in cleartext. I don't think that's an improvement... I'd even go as far as saying it's the exact opposite of what we want. While your analysis is correct (two potentially unencrypted hops), the encryption concerns in themselves should be irrelevant to the concerns of tor. Tor is not an encryption technology. The only reason for encrypting the other hops is for anonymity so that each hop only knows about its immediate peers. The question is whether an unencrypted last leg affects anonymity? Plain text communication after tor should already be considered compromised and if this leg were unencrypted it should not be considered an additional plain text compromise. -Martin Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
Re: getting more exit nodes
Martin Fick schrieb: --- Andrew [EMAIL PROTECTED] wrote: Roger Dingledine schrieb: adding much additional anonymity. (Or is it?) I believe this to be the most interesting question... since the user does not know his connection will be relayed via a client-exit, there will only be encryption up until the last relay (the one advertising itself as an exit). Therefore, even if you re-encrypt the data for transfer to the client-exit, it will now be *two* hops being able to read the user's traffic in cleartext. I don't think that's an improvement... I'd even go as far as saying it's the exact opposite of what we want. While your analysis is correct (two potentially unencrypted hops), the encryption concerns in themselves should be irrelevant to the concerns of tor. True. But... Tor is not an encryption technology. The only reason for encrypting the other hops is for anonymity so that each hop only knows about its immediate peers. The question is whether an unencrypted last leg affects anonymity? If everyone would use tor the way it was meant to be used, no problem here. But as you know, rogue exit nodes have become a problem within the tor network; this feature would provide for them a very nice cover to hide under. Since your connection is in plain text for two hops now (or at least two hops can read it as plain text), there's also two hops that can mess with your traffic. And while today it is pretty conclusive to say if someone messed with your traffic, it was the exit node (therefore this node should be considered bad), after introducing this feature that would no longer be possible (since, as was proposed, noone but the last node would even know the client-exit existed, or its IP; and even if that was openly advertised, testing for malicious tor nodes would become that much harder). It's not an attack from the outside I fear here, but one from within the network. Something tor is already very vulnerable to as it is. Regards Andrew
Re: getting more exit nodes
--- Andrew [EMAIL PROTECTED] wrote: Martin Fick schrieb: Tor is not an encryption technology. The only reason for encrypting the other hops is for anonymity so that each hop only knows about its immediate peers. The question is whether an unencrypted last leg affects anonymity? If everyone would use tor the way it was meant to be used, no problem here. But as you know, rogue exit nodes have become a problem within the tor network; this feature would provide for them a very nice cover to hide under. Since your connection is in plain text for two hops now (or at least two hops can read it as plain text), there's also two hops that can mess with your traffic. And while today it is pretty conclusive to say if someone messed with your traffic, it was the exit node (therefore this node should be considered bad), after introducing this feature that would no longer be possible (since, as was proposed, noone but the last node would even know the client-exit existed, or its IP; and even if that was openly advertised, testing for malicious tor nodes would become that much harder). It's not an attack from the outside I fear here, but one from within the network. Something tor is already very vulnerable to as it is. Fair enough, good concerns, perhaps a good argument for ensuring that client exit nodes are visible, but this is not really affected by encryption. But, perhaps authentication is important here so that client exit nodes can at least be accurately identified, good and bad ones; tor users should therefore have a say in which client exit nodes to route to? Perhaps a client exit tor node could be required to connect to all other tor nodes? This would be resource intensive, but it would allow the client exit node to act just like any other tor exit node since it could then be chosen as an exit node from any middle tor node (and thus encryption becomes important again here) and no longer requiring a fourth hop? This techniques could further be extended to middle nodes to allow them to bypass firewall restrictions. The only restriction imposed by firewalls would now become entrance nodes since they would need to accept connections from anywhere! Well, perhaps it wouldn't work since any of these special nodes could not communicate with any of these other special nodes. You could devise complicated routing algorithms to enable this to work for middle nodes too, but it is probably more complicated than it's worth. I guess sticking to exit nodes might makes this more workable. Having routing restrictions like this might make it easier to deduce paths within the cloud also. If I know that a certain node can only connect to certain other nodes, than I might easily be able to deduce the identity of nodes two hops back or forward! So much for extending this to middle nodes or making client exit nodes the third hop! I guess you guys already had that figured all out before suggesting the current exit node idea and not taking it any further! :) Of course, opening a connection to every other tor node has its problems too, for starters many cheap firewalls will potentially choke under the connection load. I think that the client exit node is a great idea though and really merits more thought. The browser plugin issue really is a separate issue and is just an implementation issue. Anyone is free to implement the tor protocol right? Whether anyone uses it is up to them? I agree with most of the technical complaints about the plugin though, although it is not uncommon for me to leave my browser open for days at a time. -Martin Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
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
Re: getting more exit nodes
Alexander Bernauer wrote: 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. Are you sure it's a good idea to encourage non-technical users, who might not understand the legal risks, to run exit nodes? Cheers, Michael
Re: getting more exit nodes
Hi, On Apr 20, 2008, at 1:32 PM, Alexander Bernauer wrote: [snip] 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. I don't think a browser plugin is a good choice for an application that can act as a Tor exit node. Please note how long it takes for a Tor node to be used by clients, and how often Users close their browsers. 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. There is another reason why I think a browser plugin is ill suited: In my opinion, users want browser plugins for a specific purpose, for example play a movie or block Flash. They don't want a plugin that does arbitrary things they don't quite understand. 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. Note that currently, any relay must be able to connect to any other relay. Sebastian
Re: getting more exit nodes
Hello Alexander, and list, that is an essential idea, which is now discussed, and that start of that development is still missing. So good to hear. First, I agree (as posted earlier), that we need a tit-for-tat Tor: Everyone who wants to surf with the IP of another peer, needs to give his IP as well, so that others can surf. That was the idea of peek-a-booty software, which stalled in development. We raised the question to have a special browser with this exit-node tor implemented to jap and roger and torpark. But noone ever came up with any solution. So I appreciate the new tit-for-tat paragdim and development start: everyone who uses tor, must be with his IP an exit node. Similar archtectures were discussed for friends of friends, e.g. over http://retroshare.sf.net - there is already code (i can send or see the feature request postings with the patch) where a friend is a proxy for all his friends.. You now mention the firewall problem... here i might be allowed to suggest as well this kind of architecture, which helps in three ways: a) surfing of all friends through my IP: psiphon or retroshare patch b) installing on certain retroshare nodes a tor node, so that both are in a superpeer modus: friends can surf over rs friends and select the ip of the friend, or the tor circuit. that is a limited design, as only friends can choose that server and for the peers from the tor network choosing this exit node, it makes no difference. so for the friends it is just a normal proxy, they share with the option to step into a tor circuit. Though--- that way one RS friend in the USA would allow many friends to choose that exit-ip. or that tor-entry ip. (without the ISP logging, as RS is encrypted transfer) an now the interesting thing c) Breaking through a firewall: RS has implemented openDHT and other RS nodes work as a STUN server, so the connection can break through every firewall. The idea is now, to use any retroshare node to make the firewall breakthrough for the TOR-Client-Firefox node. That design uses not the f2f-connections, but the network only for the firewall breakthrough (initial Stun). Of course you can install as well any central STUN server. The problem with this design is, if the (central or public known) stun server is killed (or the forwarding tor server), then many client-exit-nodes (the firefoxusers) are killed. (and of course the users doing evil things to them with the ip of the client-exit node... so here is the real problem, not showing the IP of the pseudo-exit node not in the tor-server list). You request a total change to a p2p network, away from the client-server approach. That was peek-a-booty. so your idea has two main impacts: - firewall breakthrough - hidden client-exit-nodes (covered by the IP of the proxy-forwarding (stun)server) As said: the p2p network needs no serverlist, just any user as an outproxy and every user testing TOR can accuse any IP - the one with which he surfs - to shut down the exit node. Indifferent, if it is a pseudo or normal or client exit node. I would speak then of a professional server exit node and an at-home-Firefox-private-exit-node, and because of the firewall, the private exit nodes need a stun server or reflector (term from cucme) or a proxy or a forwarding server - however you want to call it. professional exit node = Tor servers (appear in the list) refelctors = Pseudeo-exit nodes Private exit nodes = Firefox users, connecting to reflectors, getting the requests forwarded from them. So the hiding of the IP of the private exit node is not the issue.. (though with your design they do not appear in the list of the (normal tor) client, but every user can surf, see the exit-ip and take it down (= test if there is a log, if not - accuse )). That is the same problem with the emule clients.. which show the IP downloading a file. Using the STUN/proxy servers or reflectors to hide them, helps, but then the target are these STUN pseudo-server. If one is down, many private or client-exit nodes are down. And how do clients find the list of refelctors? so you have the same problem in the Firefox client, which you have now in the tor client serverlist. (Note that currently, any relay must be able to connect to any other relay.) That idea is simple: 1. I agree not to make a browser plugin, but to stick it to any other always running software. Then because of the revealing cockies while switching tor on and off in the browser, it would be good to have an own browser, with different gui colours, so that users know, with that browser: I surf with a different ip. 2. Make Tor tit-for tat for that deamon. 3. Stun the deamon with retroshare (as it is a p2p stun network and not a cental stun server) and then users need to install both. (btw. the Qt gui of RS has as well a browser widget, so you can implement as well a small browser there, or link to localhost for your normal browser.) What is then the function?: e.g. all private-exits could
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
Re: getting more exit nodes
Alexander Bernauer schrieb: 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? AFAIK the minimum is about 2-3 hours until a router descriptor is properly distributed through the directory mirrors and clients. 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? I think, any routers with uptimes less then 4-6 hours will be more or less useless for the network and rather tend to produce more traffic for distributing the router descriptor than relay for clients. But I am no expert for this kind of question. Not all Tor nodes have high uptimes. The uptime is only interesting for routers. Each router descriptor has a flag (stable) in its descriptor, which is set for routers with a certain minimum uptime and availability. In many circuits, stable routers are preferred. For details concerning all these stuff please read the technical design papers, I assume, they will be very helpful for your project. ;-) http://www.torproject.org/documentation.html.de#DesignDoc http://www.torproject.org/svn/trunk/doc/spec/dir-spec.txt http://www.torproject.org/svn/trunk/doc/spec/path-spec.txt http://www.torproject.org/svn/trunk/doc/spec/tor-spec.txt Bye, Dominik
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
Michael Rogers schrieb: Alexander Bernauer wrote: 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. Are you sure it's a good idea to encourage non-technical users, who might not understand the legal risks, to run exit nodes? This an important point. If there is a software, which establishs a Tor router on a computer without _informed_ consent of the admin, we're getting close to botnets. Something like that could severely hurt Tor's repution. It is really important for people to know beforehand what Tor (basically) does and what major legal risks it may pose in their jurisdiction. That might even go as far as a risk for their life. Bye, Dominik
Re: getting more exit nodes
On Sunday 20 April 2008 12:32:19 Alexander Bernauer wrote: 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 is an interesting idea - I submitted a proposal with broadly similar aims a little while ago. Though the approach was completely different. I suggest you write the idea up using the proposal format and post it to or-dev. That process will help you consider the security/anonymity implications of what you're suggesting. It will also reveal if there are any tricky implementation issues that need working out. A couple that occur to me: - Client traffic is being routed through an exit node that was not explicitly chosen by the client. Does this have any unintended consequences for anonymity? - Should pseudo-exits mark themselves as vanilla exits, or as something else? - What exit policy should they advertise? - How do the client-exits authenticate themselves to the pseudo-exit? Do they upload descriptors to the authorities? 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 signature.asc Description: This is a digitally signed message part.
Re: getting more exit nodes
On Sun, Apr 20, 2008 at 05:41:57PM +0200, Dominik Schaefer wrote: I think, any routers with uptimes less then 4-6 hours will be more or less useless for the network and rather tend to produce more traffic for distributing the router descriptor than relay for clients. Well, in theory the client-exit nodes don't need to send their descriptors to any users. They just need to have an association with a Tor relay so the relay learns quickly when they're available. Then the relay can advertise itself with the exit policy of the client-exit node, and so long as it has some client-exits available whenever an exit request shows up, it can pass it on. Here are a few other things that would be useful to consider before we can evaluate the idea: - Bug 98. If you run too many connections through a Tor process on Windows, the OS will crash. We (meaning Nick) are slowly working on that, but it is not yet solved. - Robert Hogan's questions in this thread are good to look at. In particular, does the relay actually advertise the client-exit's exit policy as its own? - Need to consider load balancing. Right now users will choose the relay proportional to the bandwidth it advertises. But if it's a fast relay and the client-exit node is slow, the client-exit node will get overloaded and things will be even slower than they are now. - Related to load balancing: how much additional latency are we talking about, from adding a fourth hop to the circuit? Because it would seem that you need four hops, since the relay to client-exit hop isn't adding much additional anonymity. (Or is it?) - How is the crypto going to work between the relay node and the client-exit node? Are you planning to put a Tor process on the client-exit node, or were you just hoping to put a tiny proxy on it? Probably there are more issues to explore after these. Hope that helps, --Roger
