[tor-bugs] #5462 [Tor]: Clients should alert the user if many guards are unreachable

[Tor Bug Tracker & Wiki]

#5462: Clients should alert the user if many guards are unreachable
----------------------------------------+-----------------------------------
 Reporter:  mikeperry                   |          Owner:                    
     Type:  defect                      |         Status:  new               
 Priority:  major                       |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor                         |        Version:                    
 Keywords:  tor-client, mumble-feature  |         Parent:  #5456             
   Points:                              |   Actualpoints:                    
----------------------------------------+-----------------------------------
Changes (by mikeperry):

  * keywords:  tor-client => tor-client, mumble-feature


Comment:

 Replying to [comment:9 nickm]:
 > I like the idea of killing the "last N connections thing" by
 optimistically retrying when we get a fresh consensus.  (Don't we already
 mark guards as up when we get a consensus that lists them as Running,
 though? I thought we did something like that.  We could change it from
 "mark them up" to "mark them as to-be-tested-for-upness", I guess?)
 >
 > I don't like the "re-test all the guards" logic if the number of guards
 to test could be quite large, though.  Can we limit it to some not-too-big
 number of our apparently-Running guards to try, or will a user with 20
 guards they haven't been able to connect to launch 20 connections every
 time they get a consensus?

 It sounds reasonable that in this case we should only test a random
 subset, to avoid DoSing ourselves in case this feature has weird bugs. But
 if we have more than N=20+ guards that the dirauths think are up and we
 keep trying new ones because most are down, shouldn't this also be a cause
 for concern?

 Related, we should also check if guards only appear to be up during our
 test and in the consensus, but not during normal use (to avoid active
 attacks).

 > > That solves the "Is the network live?" question implicitly through
 valid consensus download,
 >
 > Hm. I think we need to have other triggers too, as you note, because
 it's quite possible for Tor to have with a fresh consensus but no network
 yet (like, when unsuspending a laptop with Tor running on it, then
 connecting to a wireless network or something).

 Ok. CBT already has some function calls that tell us when we've recently
 read data off an orconn. We can use a similar callback for this.

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