Re: 25 tbreg relays in directory

[Scott Bennett]

 On Thu, 30 Apr 2009 16:59:58 -0400 Andrew Lewman and...@torproject.org
wrote:
On Mon, 27 Apr 2009 23:57:17 -0500 (CDT)
Scott Bennett benn...@cs.niu.edu wrote:

In general, these options seem a fine way to partition the tor
network.  Possibly more so for new releases and arbitraging the time
during which clients and relays upgrade. Tor clients already don't

 Well, the developers themselves did that a while back when they
cut off the non-V2Dir-capable clients and servers, right?

trust the relays. The risk is possibly more to the relay operator than

 How so?  Does a client refuse to use a relay whose version is not
in the server-versions list distributed in the V3 consensus documents
or the V2 status documents?

the tor clients using their relay.  It's their OS in most cases that's
at risk, not so much the Tor network.  

  b) tor clients will not choose relays whose versions do not
 match a version listed in server-versions when choosing routes for
 circuits. This could be implemented as additional code in
 circuitbuild.c or it might be implemented more simply by having the
 authorities refuse to give a Valid flag to such relays.

An option to allow your client to only select from a list of relays
running a version as agreed by the DA's as recommended seems the better
of your a vs b.

 Well, yes, I thought quite a while before suggesting a), but also
realized that there can be quite a long delay and upheaval involved in
a change to the directory standard and protocol, so I suggested the use
of b) in the interim.  Suggestion a) is, in the long run, a better approach.

We should stop talking about making the relay trust the client.  I
don't think implementing a DRM scheme serves Tor in any way.  If you

 That was not me, FWIW.  However, I did suggest that a client not trust
*itself* if its own version were not listed in client-versions in the V3
consensus or the V2 status.

think of Tor like TCP, then the whole discussion gets silly.  Tor is an
anonymizing protocol on top of tcp/ip, for now.  Hidden services and

 Right.  It would be good to have an SCTP implementation of tor someday.

such are example applications that use Tor, the protocol.

Roger and I have had conversations about this thread in taxis, train
stations, and the like as we've been traveling.  I'm sure he'll comment

 My goodness!  I had no idea that it would really generate much interest
among developers.  I only hoped so.

at some point.

 I predict that will interesting. :-)


  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: ExcludeNodes doesn't work right

[Robert Hogan]

On Thursday 30 April 2009 08:15:02 Scott Bennett wrote:
  About a day ago, I added a list of obsolete nodes, mostly running
 0.1.*.* releases, to my ExcludeNodes list in torrc.  One of those was
 TSL.  I still see TSL being chosen for routes for circuits.  I've
 noticed such apparent violations and commented upon them previously
 here.
  What I don't yet know is whether I might be misunderstanding what
 ExcludeNodes is supposed to do, based upon my understanding of the tor
 man page, which says,

 ExcludeNodes node,node,...
A  list  of  identity fingerprints, nicknames, country codes and
address patterns of nodes to never use when building a  circuit.
(Example:  ExcludeNodes SlowServer, $ABCDEFFF, {cc},
255.254.0.0/8)

 It seems to me that as soon as I send tor a SIGHUP after adding a node
 to ExcludeNodes in torrc, tor ought to begin excluding it from future
 path selections and ought also to remove it from its list of chosen
 entry guards if it is in that list.  If my understanding of what
 ExcludeNodes is supposed to do is incorrect, I'd very much appreciate
 someone letting me know and also some advice as to how to accomplish
 real, immediate exclusion of the node from any new circuits established
 by the client side of tor.

ExcludeNodes isn't respected by tor when building circuits for 'internal' 
use, e.g. directory updates. If you can confirm that the nodes are being 
chosen for circuits that are for the user's use then that would indicate a 
problem.

I think the best way of tracking it would be to do:

telnet localhost 9051
authenticate
setevents extended circ stream
set excludenodes={your exclude nodes}

then watch/log the output. if you see 'purpose=general' against a stream on 
a circuit containing an excluded route created after you set the 
excludenodes then there may be a problem worth investigating. You could 
post the suspect output here.




  Thanks for any information on this matter.


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




signature.asc
Description: This is a digitally signed message part.