getting more exit nodes

[Martin Fick]

--- Andrew <tor at kleinhirn.org> 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