Opened 2 years ago
Closed 2 years ago
#20831 closed defect (fixed)
Support existing guard torrc options better with new guard code, or deprecate them.
Reported by: | nickm | Owned by: | nickm |
---|---|---|---|
Priority: | High | Milestone: | Tor: 0.3.0.x-final |
Component: | Core Tor/Tor | Version: | |
Severity: | Normal | Keywords: | tor-guard regression TorCoreTeam201612 |
Cc: | Actual Points: | .2 | |
Parent ID: | #20822 | Points: | 2 |
Reviewer: | Sponsor: |
Description
These torrc options are guard-related, but I don't know how well the new code supports them (or in some cases, I rather suspect it doesn't).
- UseEntryGuards
- UseEntryGuardsAsDirGuards. (I vote, deprecate this.)
- NumEntryGuards
- NumDirectoryGuards. (I vote, deprecate this.)
- GuardLifetime
Child Tickets
Change History (11)
comment:1 Changed 2 years ago by
Keywords: | tor-guard added |
---|
comment:2 Changed 2 years ago by
Keywords: | regression added |
---|---|
Owner: | set to nickm |
Priority: | Medium → High |
Status: | new → accepted |
comment:3 Changed 2 years ago by
Keywords: | TorCoreTeam201612 added |
---|---|
Points: | → 2 |
comment:4 Changed 2 years ago by
Actual Points: | → .2 |
---|---|
Status: | accepted → needs_review |
comment:5 Changed 2 years ago by
I've modified ticket20831
to reinstate NumDirectoryGuards, since multiple directory guards is actually a pretty good idea (see ticket #20950).
comment:6 Changed 2 years ago by
Patch looks plausible, but I'm not entirely sold yet.
I'm not 100% persuaded that NumDirectoryGuards==3
actually offers much security, if the top primary guard is malicious. I remember the argument about malicious directory guards refusing to serve relay descriptors, but I kinda feel that we are screwed anyway if the top primary guard is evil since all circuits are going to go through it anyhow.
Also, the patch only supports multiple entry guards when it comes to primary guards, and does not try to generalize the logic to the other guard picking cases. A spec patch is definitely useful for this.
comment:7 follow-up: 9 Changed 2 years ago by
I'm not 100% persuaded that NumDirectoryGuards==3 actually offers much security, if the top primary guard is malicious. I remember the argument about malicious directory guards refusing to serve relay descriptors, but I kinda feel that we are screwed anyway if the top primary guard is evil since all circuits are going to go through it anyhow.
Right. My rationale here was more strongly influenced by one of the comments on #20909 or its kin about how having 3 directory guards prevented #20499 from causing major chaos on the network.
Also, the patch only supports multiple entry guards when it comes to primary guards, and does not try to generalize the logic to the other guard picking cases.
The choice that multiple entry guards only applies to primary guards was intentional, since if we're ever prevented from using all our primary guards, we want to be cautious about using more guards.
A spec patch is definitely useful for this.
Can do, once we decide we should do something like this.
comment:8 Changed 2 years ago by
I agree, it's important to have more than one directory guard for performance and reliability reasons. Security is secondary here.
comment:9 Changed 2 years ago by
Replying to nickm:
I'm not 100% persuaded that NumDirectoryGuards==3 actually offers much security, if the top primary guard is malicious. I remember the argument about malicious directory guards refusing to serve relay descriptors, but I kinda feel that we are screwed anyway if the top primary guard is evil since all circuits are going to go through it anyhow.
Right. My rationale here was more strongly influenced by one of the comments on #20909 or its kin about how having 3 directory guards prevented #20499 from causing major chaos on the network.
Hmm, interesting. In this case wouldn't it be ideal if Tor consulted the second primary guard, if and only if the first primary guard delivered expired/corrupted information? Instead of always picking at random between the top 3 guards?
Because with the current patch we end up exposing ourselves to 3 primary guards anyhow even if the first primary guard is totally innocent.
Are we afraid that implementing the above logic would be too much engineering time?
comment:10 Changed 2 years ago by
Squashed and rebased as ticket20831_v2.
I'm opening #21006 about reducing NumDirectory guards, and merging this to master.
My ticket20831 branch, on top of prop271_030_v1, handles these cases.
We'll need a corresponding spec update.