[tor-bugs] #7144 [Core Tor/Tor]: Implement Bridge Guards and other anti-enumeration defenses
Tor Bug Tracker & Wiki
blackhole at torproject.org
Fri Feb 24 11:05:23 UTC 2017
#7144: Implement Bridge Guards and other anti-enumeration defenses
-------------------------------------------------+-------------------------
Reporter: karsten | Owner: isis
Type: project | Status:
| needs_revision
Priority: High | Milestone: Tor:
| unspecified
Component: Core Tor/Tor | Version:
Severity: Normal | Resolution:
Keywords: SponsorZ, tor-bridge, | Actual Points:
027-triaged-1-out, 028-triage, 028-triaged, |
isis201604, isis201605, TorCoreTeam- |
postponed-201604, nickm-deferred-20160905, |
tor-03-unspecified-201612 |
Parent ID: | Points: 3
Reviewer: | Sponsor:
| SponsorS-can
-------------------------------------------------+-------------------------
Comment (by larsl):
A question about bridge guards in general: can't they be used by the next
hop after the guard to passively verify that the bridge guard really is a
bridge guard? Consider a client C and a bridge B with a bridge guard G. C
doesn't know that G is a bridge guard of B, so at some point it tries to
open the circuit C -> B -> R -> G where R is some arbitrary relay. B
inserts a loose-source routed hop to G, since that's its bridge guard, so
we get
C -> B -> G -> R -> G
Since no one will ever try to create a circuit like that directly, since R
will refuse to extend through G, R now knows that the first hop through G
must be loose-source routed, and thus G must be a bridge guard. Neither C
nor B can prevent this since C doesn't know which guards B are using, and
B can't read the encrypted extend cells intended for R.
Is this bad, or do we assume that bridge guards are detectable anyway? Or
is it actually prevented by the path-choosing algorithms somehow?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7144#comment:46>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list