Re: [tor-bugs] #31653 [Core Tor/Tor]: padding machine sending padding from relay to client closes circuit

[Tor Bug Tracker & Wiki]

#31653: padding machine sending padding from relay to client closes circuit
--+
 Reporter:  pulls |  Owner:  (none)
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:  Tor:
  |  0.4.2.x-final
Component:  Core Tor/Tor  |Version:  Tor:
  |  0.4.1.5
 Severity:  Normal| Resolution:
 Keywords:  wtf-pad circpad-researchers-want  |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by mikeperry):

 * keywords:  wtf-pad circpad => wtf-pad circpad-researchers-want


Comment:

 The #29494 implementation will change this codepath. It is reasonable for
 now to merge a workaround that just sets in_usec = 0 to ensure correct
 behavior for 0 delay in the meantime.

 There is roughly a 2/1000 chance of this happening during client rend
 circuit creation in production in 0.4.1.x (because the left edge of the
 histogram for that circuit type is 0ms and the right edge is 1000, and we
 roll the dice once on the client side and once on the relay side).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #31653 [Core Tor/Tor]: padding machine sending padding from relay to client closes circuit

[Tor Bug Tracker & Wiki]

#31653: padding machine sending padding from relay to client closes circuit
-+
 Reporter:  pulls|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.1.5
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad circpad  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by arma):

 Haven't looked at all the code, but upon reading the bug report, I also
 suspect an out-of-order send. Perhaps the code that is about to send the
 cell triggers the code to check for padding, and the code to check for
 padding sneaks in a padding cell right then, and then it returns and the
 original code sends its cell.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #31653 [Core Tor/Tor]: padding machine sending padding from relay to client closes circuit

[Tor Bug Tracker & Wiki]

#31653: padding machine sending padding from relay to client closes circuit
-+
 Reporter:  pulls|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.1.5
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad circpad  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by pulls):

 Thanks, makes sense. The workaround works, no more closed circuits with:

 {{{
 if (in_usec <= 0) {
 //return circpad_send_padding_cell_for_callback(mi);
 in_usec = 0;
   }
 }}}

 The relay wasn't branched from #29494 though, but tor-0.4.1.5.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #31653 [Core Tor/Tor]: padding machine sending padding from relay to client closes circuit

[Tor Bug Tracker & Wiki]

#31653: padding machine sending padding from relay to client closes circuit
-+
 Reporter:  pulls|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.1.5
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad circpad  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+

Comment (by mikeperry):

 The codepath in circpad_machine_schedule_padding() for 0 delay uses a
 direct call instead of a scheduled callback.

 This might be causing an out-of-order AES ctr issue where the padding cell
 is being sent before the cell that triggered it, but somehow the AES
 counters are not updated correctly for this ordering. This should not
 happen normally... Are you also using the branch from #29494 by any
 chance? That might mess with your cell ordering in this case...

 As a workaround: Can you try replacing the direct call to
 circpad_send_padding_cell_for_callback() from
 circpad_machine_schedule_padding() for the case where in_usec <0
 
(https://github.com/pylls/tor/blob/40c6f9bd887bdec7ed3bb03c690dd3d560321d48/src/core/or/circuitpadding.c#L1485)
 with an assignment of either in_usec = 0 or in_usec = 1?

 This will cause us to unwind back to libevent to call timer_set_cb() on
 the next event loop.

 Hope this helps!

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #31653 [Core Tor/Tor]: padding machine sending padding from relay to client closes circuit

[Tor Bug Tracker & Wiki]

#31653: padding machine sending padding from relay to client closes circuit
-+
 Reporter:  pulls|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor |Version:  Tor: 0.4.1.5
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad circpad  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+
Changes (by dgoulet):

 * cc: mikeperry (added)
 * milestone:   => Tor: 0.4.2.x-final


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #31653 [Core Tor/Tor]: padding machine sending padding from relay to client closes circuit

[Tor Bug Tracker & Wiki]

#31653: padding machine sending padding from relay to client closes circuit
-+--
 Reporter:  pulls|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Core Tor/Tor |Version:  Tor: 0.4.1.5
 Severity:  Normal   | Resolution:
 Keywords:  wtf-pad circpad  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--

Comment (by pulls):

 If you want to try on your own, I left the relay machine running at
 `MiddleNodes EDAF30C58D6CCF359EA062C668C7180A17076440` for now (this
 should be safe, the machine index is not used in the current protover).
 Will scrub this comment when the machine is no longer running at the
 middle.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #31653 [Core Tor/Tor]: padding machine sending padding from relay to client closes circuit

[Tor Bug Tracker & Wiki]

#31653: padding machine sending padding from relay to client closes circuit
-+--
 Reporter:  pulls|  Owner:  (none)
 Type:  defect   | Status:  new
 Priority:  Medium   |  Component:  Core Tor/Tor
  Version:  Tor: 0.4.1.5 |   Severity:  Normal
 Keywords:  wtf-pad circpad  |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+--
 Below appears to be a bug that results in a closed circuit due to a relay
 sending a padding cell (RELAY_COMMAND_DROP) to the client.

 At links below you find code for two circuit padding machines:
 1. circpad_machine_client_close_circuit_minimal
 2. circpad_machine_relay_close_circuit_minimal

 Machine 1 runs on a client on CIRCUIT_PURPOSE_C_GENERAL circuits with 3
 hops as soon as CIRCPAD_CIRC_OPENED: the only thing it does is set a timer
 1000s in the future and waits for the timer to expire. The purpose of the
 machine is to negotiate padding with the relay to activate Machine 2 on
 the middle relay.

 Machine 2 runs at the middle relay and repeatedly sends a padding cell to
 the client 1 usec after the event CIRCPAD_EVENT_NONPADDING_SENT. In other
 words, for every non-padding cell we directly add a padding cell. At the
 client, this causes `relay_decrypt_cell(): Incoming cell at client not
 recognized. Closing.` for all circuits triggering Machine 2 at the relay.
 Closing a circuit by injecting padding cells seems unintended.

 Here is part of a log from a client on info level showing how the machine
 registers, negotiates with the relay (starting Machine 2 at the relay),
 eventually fails to decrypt, and the circuit closes.

 {{{
 Sep 05 10:32:19.000 [info] circpad_setup_machine_on_circ(): Registering
 machine client_close_circuit_minimal to origin circ 3 (5)
 Sep 05 10:32:19.000 [info] circpad_node_supports_padding(): Checking
 padding: supported
 Sep 05 10:32:19.000 [info] circpad_negotiate_padding(): Negotiating
 padding on circuit 3 (5), command 2
 Sep 05 10:32:19.000 [info] link_apconn_to_circ(): Looks like completed
 circuit to [scrubbed] does allow optimistic data for connection to
 [scrubbed]
 Sep 05 10:32:19.000 [info] connection_ap_handshake_send_begin(): Sending
 relay cell 0 on circ 3296464733 to begin stream 20575.
 Sep 05 10:32:19.000 [info] connection_ap_handshake_send_begin():
 Address/port sent, ap socket 13, n_circ_id 3296464733
 Sep 05 10:32:19.000 [info] rep_hist_note_used_port(): New port prediction
 added. Will continue predictive circ building for 2355 more seconds.
 Sep 05 10:32:19.000 [info] connection_edge_process_inbuf(): data from edge
 while in 'waiting for circuit' state. Leaving it on buffer.
 Sep 05 10:32:19.000 [info] exit circ (length 3): $[manually-
 scrubbed](open) $[manually-scrubbed](open) $[manually-scrubbed](open)
 Sep 05 10:32:19.000 [info] pathbias_count_use_attempt(): Used circuit 3 is
 already in path state use attempted. Circuit is a General-purpose client
 currently open.
 Sep 05 10:32:19.000 [info] link_apconn_to_circ(): Looks like completed
 circuit to [scrubbed] does allow optimistic data for connection to
 [scrubbed]
 Sep 05 10:32:19.000 [info] connection_ap_handshake_send_begin(): Sending
 relay cell 0 on circ 3296464733 to begin stream 20576.
 Sep 05 10:32:19.000 [info] connection_ap_handshake_send_begin():
 Address/port sent, ap socket 14, n_circ_id 3296464733
 Sep 05 10:32:19.000 [info] circpad_deliver_recognized_relay_cell_events():
 Got padding cell on origin circuit 3.
 Sep 05 10:32:20.000 [info] relay_decrypt_cell(): Incoming cell at client
 not recognized. Closing.
 Sep 05 10:32:20.000 [info] circuit_receive_relay_cell(): relay crypt
 failed. Dropping connection.
 Sep 05 10:32:20.000 [info] command_process_relay_cell():
 circuit_receive_relay_cell (backward) failed. Closing.
 Sep 05 10:32:20.000 [info] circpad_circuit_machineinfo_free_idx(): Freeing
 padding info idx 0 on circuit 3 (23)
 Sep 05 10:32:20.000 [info] circpad_node_supports_padding(): Checking
 padding: supported
 Sep 05 10:32:20.000 [info] circpad_negotiate_padding(): Negotiating
 padding on circuit 3 (23), command 1
 Sep 05 10:32:20.000 [info] pathbias_send_usable_probe(): Sending pathbias
 testing cell to 0.233.9.53:25 on stream 20577 for circ 3.
 Sep 05 10:32:20.000 [info] relay_decrypt_cell(): Incoming cell at client
 not recognized. Closing.
 Sep 05 10:32:20.000 [info] circuit_receive_relay_cell(): relay crypt
 failed. Dropping connection.
 Sep 05 10:32:20.000 [info] command_process_relay_cell():
 circuit_receive_relay_cell (backward) failed. Closing.
 Sep 05 10:32:20.000 [info] pathbias_send_usable_probe(): Got pathbias
 probe request for circuit 3 with outstanding probe
 Sep 05 10:32:20.000 [info] pathbias_check_close(): Circuit 3 closed
 without successful use for reason 2. Circuit purpose 23 currently 1,open.
 Len