clients that never restart never drop old guards

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.

changed milestone to %Tor: 0.2.3.x-final

added component::core tor/tor milestone::Tor: 0.2.3.x-final priority::high resolution::fixed status::closed tor-client type::defect labels

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) {

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.

Trac:
Status: new to needs_review

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.

Ok. Retargeting to 0.2.3.

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

Trac:
Milestone: Tor: 0.2.2.x-final to Tor: 0.2.3.x-final

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.)

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).

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

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.

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

Trac:
Keywords: N/A deleted, tor-client added

Trac:
Component: Tor Client to Tor

closed

moved to tpo/core/tor#5380 (closed)