#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs