[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #7144 [Tor]: Implement Bridge Guards and other anti-enumeration defenses
#7144: Implement Bridge Guards and other anti-enumeration defenses
-------------------------+-------------------------------------------------
Reporter: karsten | Owner:
Type: project | Status: needs_review
Priority: normal | Milestone: Tor: 0.2.8.x-final
Component: Tor | Version:
Resolution: | Keywords: SponsorZ, tor-bridge,
Actual Points: | 027-triaged-1-out, TorCoreTeam201509
Points: | Parent ID:
-------------------------+-------------------------------------------------
Comment (by isis):
I have revised the original prop!#188 text to reflect some (mostly minor)
details discovered during implementation. The changes are in my `prop188`
[https://gitweb.torproject.org/user/isis/torspec.git/log/?h=prop188
branch]; however, I have
[https://gitweb.torproject.org/torspec.git/tree/proposals/188-bridge-
guards.txt?id=97baa255 already merged them into the common torspec repo].
I hope it was okay to for me to merge that! I felt like I shouldn't merge
my own commitsâ then I thought it'd be okay because it's ''only
documentation'' and it's now sort of "my" proposal. In the end, I decided
that it was probably okay, since it seems easier for others to audit my
code and follow my specification side-by-side â with the spec already
updated â than needing to review both separately. If this was not okay,
please let me know, and I'll revert my commit and never do that again.
The changes include:
* ADD a new section detailing loose-source routed circuits, including:
- How the circuit should appear to the OP, the bridge, and the
bridge guard,
- How the hop(s) in the path is/are chosen,
- How the first hop is handled and how circuit extension is
handled, in a generalised sense (i.e. not specific to a bridge
using bridge guards),
- Which cell types are used and how they are chosen,
- When the original create cell is answered (in relation to when
cells are sent to the other additional hops),
- What should be done when relay cells are received when the
additional hops in the loose-source routed circuit are not
fully constructed,
- How the circuit crypto and cell digests for incoming/outgoing
relay cells works (again, in a generalised sense, i.e. not
specific to bridges using bridge guards),
- How and whether a given relay cell is treated as "recognized",
- Under what circumstances (based on whether a stream is attached
and which relay command was sent) should cause a node which
uses loose-source routed circuits to drop a relay cell or mark
a circuit for close, and,
- When and what statistics should be gathered for loose-source
routed circuits.
* UPDATE and clarify the example loose-source routed circuit
construction (the original one from the proposal which was specific
to a client using a bridge that uses bridge guards).
* CHANGE the "Make it harder to tell clients from bridges" section
which described the tradeoffs between using CREATE versus
CREATE_FAST cells for the first additional hop (i.e. the bridge
guard). Those concerns is no longer entirely relevant, since, in
the meantime, we've introduced the NTor handshake and it's
extremely likely that both the client and the bridge will use
CREATE2 for all their hops.
* ADD a new section on enumerating bridges via the behaviours
inherent to bridge reachability testing.
* REMOVE open question (from the very end of the proposal) regarding
whether the standard guard selection algorithms are adequate. They
are. (Even if they are convoluted and overly-complicated.)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7144#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs