Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#5380 closed defect (fixed)

clients that never restart never drop old guards

Reported by: arma Owned by:
Priority: High Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

When we get a consensus we check whether to drop guards that have been down long enough.

But we only compare chosen_on_date to now when we're loading the state file, which we only do at start.

So if the Tor client stays running for more than a month or two, its guard behavior deviates from normal.

Discovered while talking to Tariq about his guard simulation attack graphs and trying to puzzle through his unintuitive results.

Child Tickets

Change History (10)

comment:1 Changed 8 years ago by arma

Here's the minimal patch:

diff --git a/src/or/circuitbuild.c b/src/or/circuitbuild.c
index 3948008..a0216d1 100644
--- a/src/or/circuitbuild.c
+++ b/src/or/circuitbuild.c
@@ -3862,6 +3867,8 @@ entry_guards_compute_status(const or_options_t *options, 
 
   if (remove_dead_entry_guards(now))
     changed = 1;
+  if (remove_obsolete_entry_guards(now))
+    changed = 1;
 
   if (changed) {
     SMARTLIST_FOREACH_BEGIN(entry_guards, entry_guard_t *, entry) {

comment:2 Changed 8 years ago by arma

Status: newneeds_review

See bug5380 in my git repo. Currently aimed at maint-0.2.2, but I could easily be argued into aiming at 0.2.3.

comment:3 Changed 8 years ago by Sebastian

Hrm. wanoskarnet has a good point about remove_obsolete_entry_guards() not being about rotating guards. Seems to me we should make a better fix, and target it on 0.2.3, and not put this into 0.2.2. It can be used by your guards as a fingerprint that you're on 0.2.2, but there's better fingerprints for that. I suspect the impact on the network is negligible, because if you regularly update your Tor (which you would need to do in order to get this fix) you automatically rotate guards when Tor gets started anew, and if you don't, it doesn't matter that we put out a new version.

comment:4 Changed 8 years ago by arma

Milestone: Tor: 0.2.2.x-finalTor: 0.2.3.x-final

Ok. Retargeting to 0.2.3.

By "a better fix", what did you have in mind?

comment:5 Changed 7 years ago by arma

Bug remains. Maybe I should merge this fix while I wait to see what a better fix might be?

(Also, I don't buy the logic that the fix is useless for people running 0.2.2.35 since they won't upgrade. It is easily possible that your 0.2.2.35 Tor has been running since 2011. I hope 0.2.2.36 will also go months without a revision.)

comment:6 in reply to:  description Changed 7 years ago by arma

Replying to arma:

So if the Tor client stays running for more than a month or two, its guard behavior deviates from normal.

Actually, it's worse: if the client stays running for a week, and it would have dropped its old guard on day 1 of that week, it doesn't. This turns things into a subtle statistical attack (which still seems bad).

comment:7 Changed 7 years ago by Sebastian

the better fix would be to split refactor the function (and split out some stuff) so the functions actually only do what they're supposed to do, iirc

comment:8 Changed 7 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Merging Roger's fix for 0.2.3.x, and closing. Splitting the function might be good; I added an XXXX comment to that effect.

comment:9 Changed 7 years ago by nickm

Keywords: tor-client added

comment:10 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.