Re: getting more exit nodes

[Scott Bennett <bennett@xxxxxxxxxx>]

     On Fri, 25 Apr 2008 11:15:51 +0200 Alexander Bernauer <alex-tor@xxxxxxxxxx>
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 1790         *
**********************************************************************