#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 12 months ago by dgoulet

Keywords: tor-guard added

comment:2 Changed 12 months ago by nickm

Keywords: regression added
Owner: set to nickm
Priority: MediumHigh
Status: newaccepted

comment:3 Changed 12 months ago by nickm

Keywords: TorCoreTeam201612 added
Points: 2

comment:4 Changed 12 months ago by nickm

Actual Points: .2
Status: acceptedneeds_review

My ticket20831 branch, on top of prop271_030_v1, handles these cases.

We'll need a corresponding spec update.

comment:5 Changed 11 months ago by nickm

I've modified ticket20831 to reinstate NumDirectoryGuards, since multiple directory guards is actually a pretty good idea (see ticket #20950).

comment:6 Changed 11 months ago by asn

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 Changed 11 months ago by 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.

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 11 months ago by teor

I agree, it's important to have more than one directory guard for performance and reliability reasons. Security is secondary here.

comment:9 in reply to:  7 Changed 11 months ago by asn

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 11 months ago by nickm

Squashed and rebased as ticket20831_v2.

I'm opening #21006 about reducing NumDirectory guards, and merging this to master.

comment:11 Changed 11 months ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Merged!

Note: See TracTickets for help on using tickets.