[tor-bugs] #25882 [Core Tor/Tor]: clients not detecting stale onion service introduction points

[Tor Bug Tracker & Wiki]

#25882: clients not detecting stale onion service introduction points
--------------------------+------------------------------------
 Reporter:  cypherpunks   |          Owner:  (none)
     Type:  defect        |         Status:  assigned
 Priority:  Medium        |      Milestone:  Tor: 0.3.4.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:  tor-hs        |  Actual Points:
Parent ID:  #22455        |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by cypherpunks):

 I ran Tor for a few days with the patch suggested in comment:13.

 Indeed, we did see circuits reaped in state 11, so messages like this
 appeared in the log after each one:

 {{{
 Failed intro circ [scrubbed] to [scrubbed] (awaiting ack). Removing from
 descriptor.
 }}}

 These messages were followed by messages like this, where "2" might be
 another number:

 {{{
 rend_client_report_intro_point_failure(): 2 options left for [scrubbed].
 }}}

 Unfortunately the number of "options" left never decreased.  I suspect
 that the reason for this is that in {{{circuitlist.c}}}:

 {{{
       /* treat this like getting a nack from it */
       log_info(LD_REND, "Failed intro circ %s to %s (awaiting ack). %s",
           safe_str_client(rend_data_get_address(ocirc->rend_data)),
 safe_str_client(build_state_get_exit_nickname(ocirc->build_state)),
           timed_out ? "Recording timeout." : "Removing from descriptor.");
 rend_client_report_intro_point_failure(ocirc->build_state->chosen_exit,
                                              ocirc->rend_data,
                                              timed_out ?
                                              INTRO_POINT_FAILURE_TIMEOUT :
                                              INTRO_POINT_FAILURE_GENERIC);
 }}}

 When {{{rend_client_report_intro_point_failure}}} is called, the first
 argument is the '''chosen exit of this circuit''', which in the case of
 rendezvous circuits is the rendezvous point, not the intro point.
 However, it is the intro point that is in the descriptor, and (based on
 the above) it is the intro point that is indeed problematic.

 Yes, it is the failure of the {{{REND}}} circuit that in this case
 indicates that the intro point is bad.

 If it is indeed the case that Tor sets up a {{{REND}}} circuit and a
 {{{INTRODUCE}}} circuit in one-to-one correspondence, as is suggested by
 the fact that 89 circuits each were in {{{REND}}} and {{{INTRODUCE}}} mode
 in the log fragment analysed in comment:13, then is it possible to know to
 which intro point a given {{{REND}}} circuit corresponds from the internal
 data structure of the {{{REND}}} circuit?  If so, then we could pass the
 '''intro point''' as the first argument to
 {{{rend_client_report_intro_point_failure}}} instead.

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