[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:  isis
     Type:  project                              |         Status:
 Priority:  High                                 |  needs_revision
Component:  Tor                                  |      Milestone:  Tor:
 Severity:  Normal                               |  0.2.8.x-final
 Keywords:  SponsorZ, tor-bridge,                |        Version:
  027-triaged-1-out, TorCoreTeam201509,          |     Resolution:
  028-triage, 028-triaged                        |  Actual Points:
Parent ID:                                       |         Points:  medium
  Sponsor:                                       |
-------------------------------------------------+-------------------------

Comment (by isis):

 Replying to [comment:21 nickm]:
 > Okay, I came here to drink coffee and review code, and my doctor tells
 me I shouldn't drink so much coffee.  I'll look at the smaller ones first.
 >

 Thanks, Nick! I owe you a beverage at the next meeting in Valencia. :)

 > […]
 >
 > 43670da13937 Generalise logic for whether a circuit_t supports ntor.
 >    * Yes but we should also open a ticket here for removing
 *_supports_ntor() entirely; we no-longer allow TAP-only relays on the
 network.  (Opened as #17882)

 I thought it odd that we still had a function which should only ever
 return true, but I didn't want to go off refactoring pieces of code when
 it wasn't strictly necessary (since these patches are already large).

 > […]
 >
 > 1568e1449278 Redefine CIRCUIT_IS_ORIGIN to use ORIGIN_CIRCUIT_MAGIC, not
 purpose.
 >    * lgtm.  There is a too-wide line here, I think, but please don't fix
 it now; I'll get it when I do "make check-spaces" after merge.

 Whoopsies.

 > 6daf9165951d Make logic for choosing create cell type be agnostic to
 circuit type.
 >    * hmm. I know this isn't new, but the
 `!cpath->extend_info->onion_key` check looks poor to me, since it will
 fail once no-TAP relays are a reality.  Probably doesn't need to get fixed
 on this branch though.

 What if I were to move it below the `if (server_mode(options))` check?
 That way, (at least in the future) we'll never accidentally use
 CREATE_FAST cells between ORs, where one has no `onion_key`.  Separate
 ticket?

 > b5546456b415 Check circuit types before casting in
 relay_send_command_from_edge_().
 >    * If we're going to make this change, we need to recognize that this
 function isn't really "from_edge" any more -- a cell sent outwards from a
 bridge is not sent "from_edge".   Renaming this function might be
 overkill, but we should document its new semantics in its comments.

 I made a coccinelle script for the transformation. It's added, applied,
 and cleaned up (whitespace fixes and renaming the actual function
 declaration and implementation ) in:

     *
 [https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug7144_r1&id=781c27fb238cc8148763b5e9113113851ebd6d9f
 781c27fb] Add coccinelle script for renaming
 relay_send_command_from_edge().
     *
 [https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug7144_r1&id=cd3d7f9c0b8cc9a8142471bd9b5e6a72dd2ea8c6
 cd3d7f9c] Apply relay_send_command_from_edge.cocci transformations.
     *
 [https://gitweb.torproject.org/user/isis/tor.git/commit/?h=bug7144_r1&id=376f3b41f227c8c725500e3ac212ca0388978e7a
 376f3b41] Manual changes after relay_send_command_from_edge.cocci
 transformations.

 The coccinelle script can easily be applied to any current/further patches
 which call either `relay_send_command_from_edge()` or
 `relay_send_command_from_edge_()`.

 > […]
 >
 > 45d2457abd5c Add unittests for loose.c.
 >   * Changes to non-test code all lgtm
 >   * Tests seem okay after a quick skim.  If you haven't already done so,
 please run them under valgrind to make sure they don't leak.

 I ran them under valgrind while writing them. There's no leaks, AFAICT.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/7144#comment:27>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online