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, TorCoreTeam201512,               |        Version:
  201511-deferred                                |     Resolution:
Parent ID:                                       |  Actual Points:
  Sponsor:                                       |         Points:  medium
-------------------------------------------------+-------------------------

Comment (by mikeperry):

 Replying to [comment:33 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?

 No. I clarified it in a fixup, though. Basically we want to know as early
 as possible if we should be padding the channel or not.

 > 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?

 It does not. The code assumes that 1 hop means "don't care about traffic
 analysis" and 3 hops means "do care". And remember that padding is a
 property of the channel, so if either Tor2Web or (R)SOS happen to build 3
 hop circuits on a channel, the channel will become padded.

 As we discussed I think basically we don't want to pad these, though,
 primarily because it will mean a lot of overhead (#17857).

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

 We definitely don't want to pad directory connections. We also want to
 start padding as early as possible. For clients,
 circuit_send_next_onion_skin() is an earlier decision point than
 circuit_receive_relay_cell().

 > 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?

 This was initially higher, but Karsten actually suggested I set it at 1
 when I asked him for a better value. He said the 24 hour binning+rounding
 was sufficient, and we should be focused on that value (which he gave some
 suggestions for).

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

 I think this may be risky, as we'd want a similar level of sanitization as
 the rephist data. I'm inclined to leave it out for now, and just keep an
 eye on the extra-info data.

 > 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
 > }}}

 I fixed this by making a single MAX_LINK_PROTO in connection_or.h.

 A fixup commit is now pushed on top of the netflow_padding-v4 branch. I
 will also soon be pushing fixups for the other tickets, too.

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