--- 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