Opened 6 years ago

Closed 2 years ago

#8782 closed enhancement (fixed)

Don't give up so easily on your guards if the consensus calls them Running

Reported by: arma Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.7
Severity: Normal Keywords: tor-client, tor-guards-revamp
Cc: asn Actual Points:
Parent ID: Points: 4.5
Reviewer: Sponsor: SponsorU-can

Description

If your guard ever fails to do everything you demand, you'll mark it as not running for several hours (i.e. until you get a new consensus that tells you to forgive it). So an attack to railroad you onto the adversary's guard (even if temporarily, which isn't so bad for a normal client but is super scary for a hidden service) gets cheaper.

It would be wise to forgive guards in the "we decided they're down but our consensus still says they're up" state much more quickly and often. That changes the attack from a serial "get us to mark each guard down one at a time" to either requiring you to do it in a much shorter time frame, or the more expensive parallel "keep a growing set of guards all down until the victim chooses ours".

(A discussion with rpw at 29c3 reminded me of this issue, and now ongoing discussions with Rob re-remind me of it.)

Child Tickets

Change History (26)

comment:1 Changed 6 years ago by arma

(I called it an 'enhancement', because the feature is 'you're more safe'.)

comment:2 Changed 6 years ago by arma

In theory this won't induce that many further connections, since it will only happen in the case where our guard goes down while we're using it. Assuming I guess that guards don't do so that often.

The trick here will be to check pretty often while avoiding loops where we try a new connection, become convinced that he's up, reset our re-check timing, realize he's down for the same reason we did last time, repeat.

We'll want to make a decision about whether we want to go the "when one of our guards gets into this state, queue it onto a retry schedule" route, or something fancier with the aim of achieving similar goals with fewer retries, like "when one of our guards gets into this state, retry all the guards currently in this state".

Speaking of these fancier options, check out the first_contact variable in entry_guard_register_connect_status(). Do we already accidentally do something like this ticket? Is it enough?

comment:3 Changed 6 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.6.x-final

comment:4 Changed 5 years ago by nickm

Keywords: 026 added
Parent ID: #11480

comment:5 Changed 5 years ago by nickm

Keywords: 026-triaged-1 added; 026 removed

comment:6 Changed 5 years ago by nickm

Milestone: Tor: 0.2.6.x-finalTor: 0.2.7.x-final

comment:7 Changed 5 years ago by nickm

Status: newassigned

comment:8 Changed 4 years ago by nickm

Keywords: 027-triaged-1-in added

Marking some tickets as triaged-in for 0.2.7 based on early triage

comment:9 Changed 4 years ago by isabela

Keywords: SponsorU added
Points: medium/large
Priority: normalmajor
Version: Tor: 0.2.7

comment:10 Changed 4 years ago by nickm

Milestone: Tor: 0.2.7.x-finalTor: 0.2.8.x-final

comment:11 Changed 4 years ago by nickm

Keywords: SponsorU removed
Sponsor: SponsorU

Bulk-replace SponsorU keyword with SponsorU field.

comment:12 Changed 4 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final
Status: assignednew

Turn most 0.2.8 "assigned" tickets with no owner into "new" tickets for 0.2.9. Disagree? Find somebody who can do it (maybe you?) and get them to take it on for 0.2.8. :)

comment:13 Changed 3 years ago by isabela

Sponsor: SponsorUSponsorU-can

comment:14 Changed 3 years ago by asn

Parent ID: #11480
Severity: Normal

comment:15 Changed 3 years ago by nickm

Keywords: tor-guards-revamp added

comment:16 Changed 3 years ago by isabela

Points: medium/large4.5

comment:17 Changed 3 years ago by asn

Milestone: Tor: 0.2.9.x-finalTor: 0.2.???

Moving this out of 0.2.9. It's a great idea and an important issue, but we are missing a proposal. prop259 has no intentions of fixing this issue.

comment:18 Changed 3 years ago by asn

Cc: asn added

comment:19 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:20 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:21 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:22 Changed 2 years ago by nickm

Keywords: 027-triaged-in added

comment:23 Changed 2 years ago by nickm

Keywords: 027-triaged-in removed

comment:24 Changed 2 years ago by nickm

Keywords: 027-triaged-1-in removed

comment:25 Changed 2 years ago by nickm

Keywords: 026-triaged-1 removed

comment:26 Changed 2 years ago by nickm

Resolution: fixed
Status: newclosed

Under prop271, guards no longer act as described here: we don't want for a new consensus before retrying a guard.

Note: See TracTickets for help on using tickets.