[tor-bugs] #2355 [Tor Client]: change the meaning of UseBridges

[Tor Bug Tracker & Wiki]

#2355: change the meaning of UseBridges
-------------------------------------+--------------------------------------
        Reporter:  anonym            |         Type:  enhancement
          Status:  new               |     Priority:  minor      
       Milestone:  Tor: unspecified  |    Component:  Tor Client 
         Version:                    |     Keywords:             
          Parent:                    |       Points:             
Actualpointsdone:                    |   Pointsdone:             
    Actualpoints:                    |  
-------------------------------------+--------------------------------------

Comment(by anonym):

 Replying to [comment:3 arma]:
 > This seems like an important feature that is worth adding.

 Agreed.

 > Another approach I'd heard pondered was that Vidalia would give you a
 popup on your first start, asking if you were planning to put some bridges
 in or if it should just proceed to try the public Tor network.

 Yeah, I wrote a patch for this: a pop-up (that is T(A)ILS specific, but it
 can easily be made generic of course) is shown if UseBridges is set, but
 no bridge is configured, and Vidalia is started with a new "-bridgeconf"
 parameter. If this enhancement to UseBridges is implemented I could send
 my Vidalia patch upstream with some modifications to make it more generic.

 > If we go with that design, I guess Vidalia could start Tor with this
 'usebridges 1' option while it waited for the user to choose one. Or
 Vidalia could simply not start Tor until it knows how it wants it to be
 configured.
 >
 > Would that be a helpful feature for tails as well, or is it orthogonal?

 We want something like this, yes. Exactly what we want, I guess, is this:

 UseBridges is a tristate with possible values 0, 1 and auto, defaulting to
 auto: 1 and 0 behaves as before, auto behaves as 1 iff any bridges are
 configured. Furthermore, it's possible to start Tor with UseBridges 1 and
 no bridges configured (old behavious is to reject the config) -- in this
 situation Tor simply idles as it waits for a bridge to be configured
 through the control port.

 I have played around with the Tor sources, but it was the first time I
 really looked into them, so it's very possible I have overlooked some
 things. I have got the above to work (I think, see attached patch), but
 there are some FIXME's that need further work. In addition, the patch
 makes two other bridge related things:

 1) Tor only chooses a bridge as entry if it is configured. So if you add a
 bridge to Tor, get its descriptors etc. so it's ready for use, and then
 remove it and add another bridge, new circuits will be build using only
 the new bridge. At least it appears to me that Tor without the patch
 continues to use the removed bridge.

 2) Whenever a bridge is added/removeded, all circuits are torn down (just
 like with ExcludeNodes and similar options). It's a bit crude as if you
 have a bridge A configured, and then add a bridge B (so you now have A and
 B configured), all circuits using A will be torn down, which is a bit
 unnecessary.

 As I said, it my first look into the Tor sources, so I might have done
 this in suboptimal way. And as I said there are some parts (marked with
 FIXME's) that I know something probably must be done about. Input on those
 issues are very welcome.

 Oh, and one thing I really want, but haven't figured out how to do
 properly, is to make Tor faster in bootstrapping with added bridges. I
 want Tor to immediately and explicitly try to fetch the bridge descriptors
 when a bridge is added instead of having that happen during the scheduled
 dir updates (which can take some time). Any input on how to do that
 properly would be greatly appreciated.

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