Re: [tor-bugs] #16861 [Tor]: Pad Tor connections to collapse netflow records

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#16861: Pad Tor connections to collapse netflow records
-------------------------------------------------+-------------------------
 Reporter:  mikeperry                            |          Owner:
     Type:  enhancement                          |  mikeperry
 Priority:  High                                 |         Status:
Component:  Tor                                  |  needs_review
 Severity:  Normal                               |      Milestone:  Tor:
 Keywords:  028-triage, 028-triaged,             |  0.2.8.x-final
  pre028-patch TorCoreTeam201511                 |        Version:
Parent ID:                                       |     Resolution:
  Sponsor:                                       |  Actual Points:
                                                 |         Points:  medium
-------------------------------------------------+-------------------------
Changes (by mikeperry):

 * status:  needs_revision => needs_review


Comment:

 Ok, this is finally ready! It passes all unit tests and chutney tests,
 I've tested it extensively myself on both chutney and my own TBB. It has
 been refactored a few times, and I fixed all of Nick's concerns, and
 almost all of my concerns from comment:18 and comment:19. I watched the
 log behavior quite closely, as well. Here is the commit to review:
 https://gitweb.torproject.org/mikeperry/tor.git/commit/?h=netflow_padding-v4&id=8c2d53a33aff55c614ac48047dbbb0b15157b56f

 The primary implementation is in channelpadding.c - that c file has 98%
 line coverage and 81% branch coverage via the unit tests. Not sure what
 chutney brings it up to.

 I only have one more question: Are channel_timestamp_xmit,
 channel_timestamp_recv, and channel_timestamp_active the right places to
 signify network activity? They seem like it to me, but I am a bit lost in
 all of the channel to connection_or to orcon buffers to bufferevents (or
 not) to libevent to kernel layering and how it all shakes out in practice.
 The comment in channel_timestamp_active also makes it sound like it is not
 for actual wire activity, but it is also the only thing being called in
 several places where there is wire activity (such as the initial TLS conn
 setup). Unfortunately, it is also called in some places that don't clearly
 map to wire activity... Will that matter in practice? Should I make a
 separate activity callback just for this code?

 That branch also has commits for the two child tickets of this bug (#17592
 and #17604). Those are also well tested. I will set needs review on those
 tickets for those two commits.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/16861#comment:32>
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