Opened 6 months ago

Closed 5 months 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 6 months ago by dgoulet

  • Keywords tor-guard added

comment:2 Changed 6 months ago by nickm

  • Keywords regression added
  • Owner set to nickm
  • Priority changed from Medium to High
  • Status changed from new to accepted

comment:3 Changed 6 months ago by nickm

  • Keywords TorCoreTeam201612 added
  • Points set to 2

comment:4 Changed 6 months ago by nickm

  • Actual Points set to .2
  • Status changed from accepted to needs_review

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

We'll need a corresponding spec update.

comment:5 Changed 5 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 5 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 follow-up: Changed 5 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 5 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 5 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 5 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 5 months ago by nickm

  • Resolution set to fixed
  • Status changed from needs_review to closed

Merged!

Note: See TracTickets for help on using tickets.