[tor-bugs] #20831 [Core Tor/Tor]: Support existing guard torrc options better with new guard code, or deprecate them.
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Dec 14 01:19:28 UTC 2016
#20831: Support existing guard torrc options better with new guard code, or
deprecate them.
-------------------------------------------------+-------------------------
Reporter: nickm | Owner: nickm
Type: defect | Status:
| needs_review
Priority: High | Milestone: Tor:
| 0.3.0.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: tor-guard regression | Actual Points: .2
TorCoreTeam201612 |
Parent ID: #20822 | Points: 2
Reviewer: | Sponsor:
-------------------------------------------------+-------------------------
Comment (by asn):
Replying to [comment:7 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?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/20831#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list