[tor-bugs] #5462 [Tor]: Clients should alert the user if many guards are unreachable
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri Nov 9 08:30:47 UTC 2012
#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
More information about the tor-bugs
mailing list