[tor-bugs] #7144 [Tor]: Implement Bridge Guards and other anti-enumeration defenses

[Tor Bug Tracker & Wiki]

#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