[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: 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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs