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

[Tor Bug Tracker & Wiki]

#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, 201511-deferred,                 |        Version:
  TorCoreTeam201601, 201512-deferred             |     Resolution:
Parent ID:                                       |  Actual Points:
  Sponsor:                                       |         Points:  medium
-------------------------------------------------+-------------------------
Changes (by mikeperry):

 * status:  needs_revision => needs_review


Comment:

 Ok, I have a new set of patches ready in mikeperry/netflow_padding-
 v4_squashed+rebased. They are rebased on top of nickm/fast_channel_lookup
 and are ready to be squashed. See mikeperry/netflow_padding-v4_squashed if
 you want to spot-check the full history. The two heads are identical in
 content.

 For this bug, all of the issues from comment:40 should now be fixed, with
 the following provisos:

 1. I did notice another issue with time. After thinking about it, I think
 I still prefer explicit checks rather than simply using monotonic time,
 because if the clock jumps backwards, I don't want to sit around not
 sending padding forever while we wait for it to catch up with itself. I'd
 rather handle each case explicitly, though I admit it is kinda mind-
 bending either way we go. I think I did it right?
 1. I changed timestamp_active_highres to timestamp_xfer_highres. xfer
 seemed to capture what I want. I left it non-cached, though, due to it
 being equivalent in speed to time(), and I want the resolution.
 1. Am I right that directionality does not apply to link-level cells? Only
 circuit RELAY cells, yes?
 1. I left the CELL_PADDING and CELL_PADDING_NEGOTIATE handling in
 channeltls.c. Is command.c a better place for some reason?
 1. I left the test in circuit_send_next_onion_skin(). Happy for a
 suggestion for a better place. It seems OK to me, though, given that is
 where the control port decides to tell the controller about a very similar
 thing.
 1. I did not change the is_client stuff. If you have concrete suggestions
 here, happy to hear them. Still don't like purely behavioral decisions,
 though.

 I think I'd prefer these fixup commits squashed when merged, so feel free
 to do that if you don't see any more major issues. Again, mikeperry
 /netflow_padding-v4_squashed+rebased should be all ready for squash and
 merge, or squash and another round of fixups.

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