[tor-bugs] #2510 [Tor Client]: bridge users who configure the non-canonical address of a bridge switch to its canonical address

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Tue Feb 8 09:44:35 UTC 2011


#2510: bridge users who configure the non-canonical address of a bridge switch to
its canonical address
------------------------+---------------------------------------------------
 Reporter:  arma        |       Owner:                    
     Type:  defect      |      Status:  needs_review      
 Priority:  major       |   Milestone:  Tor: 0.2.2.x-final
Component:  Tor Client  |     Version:                    
 Keywords:              |      Points:                    
   Parent:              |  
------------------------+---------------------------------------------------

Comment(by arma):

 Messy issue number 1: routerlist_descriptors_added(), the function that
 calls learned_bridge_descriptor(), gets called after
 router_add_to_routerlist() and thus after we've called
 signed_desc_append_to_journal() and written it to our cached-
 descriptors.new file. Oops. Of course, we don't want to be modifying the
 descriptor anyway, since then the signature will fail.

 The specific problem that issue number 1 causes is that when we start our
 Tor again, it reads in the descriptor for the bridge at 128.31.0.34, reads
 from its state file that a node with that fingerprint is a guard node, and
 tries to connect to it (I think this is a separate bug). Then later, we
 get the new descriptor for 128.31.0.34 by fetching it from 128.31.0.39.
 But rather than giving us a chance to call our function, it instead says
 {{{
 Feb 08 04:22:37.008 [debug] router_parse_list_from_string(): Read router
 'bridge', purpose 'bridge'
 Feb 08 04:22:37.008 [info] router_load_routers_from_string(): 1 elements
 to add
 Feb 08 04:22:37.008 [info] router_add_to_routerlist(): Dropping descriptor
 that we already have for router 'bridge'
 }}}
 and that's the end of that. One workaround would be to drop bridge
 descriptors as we read them from disk if their IP address isn't a
 configured bridge. Which leads to:

 Messy issue number 2: should we still do this address rewriting if we got
 the descriptor from the bridge authority? After all, one of the features
 we talk about is being able to 'follow' a bridge on a dynamic IP address
 from day to day, so long as you can still reach the bridge authority. Does
 that mean we should only do the rewriting when we got the descriptor from
 a direct request, and leave the address:port alone when we learned it from
 the directory authority?

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2510#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list