[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 TorCoreTeam201511                 |        Version:
Parent ID:                                       |     Resolution:
  Sponsor:                                       |  Actual Points:
                                                 |         Points:  medium
-------------------------------------------------+-------------------------

Comment (by teor):

 Code review:

 Looks great, just a few questions:

 I'm not sure about the comment in circuit_send_next_onion_skin:
 {{{
 +      /* If this is not a one-hop tunnel, the channel is being used for
 +       * stuff other than non-directory traffic. That means we want to
 +       * pad it.
 +       */
 }}}
 Does it need to be updated?

 And the implementation changes in circuit_receive_relay_cell:
 {{{
 +   * We assume we're more than one hop if either the previous hop
 +   * is not a client, or if the previous hop is a client and there's
 +   * a next hop. Then, circuit traffic starts at RELAY_EARLY, and
 }}}

 Tor2Web clients use one-hop tunnels for user traffic, and hidden servers
 running (Rendezvous) Single Onion Services are about to.

 Does this code correctly distinguish between one-hop directory circuits
 and one-hop Tor2Web/(R)SOS circuits?

 I think we need to remove the one-hop checks entirely, and just depend on
 the RELAY cells.

 In rep_hist_get_predicted_ports:
 {{{
 + // XXX: Change this if ReducedConnectionPadding is set.
  predicted_circs_relevance_time =
 get_options()->PredictedPortsRelevanceTime;
 }}}
 Do you still need to fix this?

 Regarding MIN_CELL_COUNTS_TO_PUBLISH:

 After the network is mainly 0.2.8, relays which aren't using padding may
 become quite rare.
 Do we want to set MIN_CELL_COUNTS_TO_PUBLISH to something higher than 1,
 to hide relays with small counts and relays with 0 counts together?

 Also, do we want to include a total padding amount in the heartbeat
 messages?

 Nitpicks:

 Do we want to define MAX_LINK_PROTO_TO_LOG based on
 MIN_LINK_PROTO_FOR_CHANNEL_PADDING, or doesn't that make sense?
 {{{
 +#define MAX_LINK_PROTO_TO_LOG 5
 }}}

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