[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #25882 [Core Tor/Tor]: clients not detecting stale onion service introduction points
#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):
The snippet of code in comment:11 is not called unless the circuit is in
{{{CIRCUIT_PURPOSE_C_INTRODUCE_ACK_WAIT}}}. It would be interesting to
confirm the purpose of the circuit just before it is deleted. More
generally, it would be interesting to confirm how the circuit purposes
change for the circuits that are in place during the period covered by the
logs after we reach a bad intro point. In the case of {{{debug.log.A}}},
we can list all of the state transitions after 06:30:20:
{{{
$ tail -91500 debug.A.log | grep "changing purpose" | sed -e "s/.*[0-9]
from/from/g" | sort | uniq -c
89 from "General-purpose client" (5) to "Hidden service client:
Connecting to intro point" (6)
89 from "General-purpose client" (5) to "Hidden service client:
Establishing rendezvous point" (9)
3 from "General-purpose client" (5) to "Measuring circuit timeout"
(13)
89 from "Hidden service client: Connecting to intro point" (6) to
"Hidden service client: Waiting for ack from intro point" (7)
89 from "Hidden service client: Establishing rendezvous point" (9) to
"Hidden service client: Pending rendezvous point" (10)
89 from "Hidden service client: Pending rendezvous point" (10) to
"Hidden service client: Pending rendezvous point (ack received)" (11)
89 from "Hidden service client: Waiting for ack from intro point" (7)
to "Hidden service client: Received ack from intro point" (8)
}}}
We can represent the purpose changes in a state transition diagram, as
follows, where the numbers in the circles represent the purposes, and the
values on the edges represent the number of state transitions observed:
[[Image(tor-25882.png, 100%)]]
For reference, here is a table containing the states:
||= State =||= Tag in {{{or.h}}} =||= Description =||
|| 5 || {{{CIRCUIT_PURPOSE_C_GENERAL}}} || "General-purpose client" ||
|| 6 || {{{CIRCUIT_PURPOSE_C_INTRODUCING}}} || "Hidden service client:
Connecting to intro point" ||
|| 7 || {{{CIRCUIT_PURPOSE_C_INTRODUCE_ACK_WAIT}}} || ""Hidden service
client: Waiting for ack from intro point ||
|| 8 || {{{CIRCUIT_PURPOSE_C_INTRODUCE_ACKED}}} || "Hidden service client:
Connecting to intro point" ||
|| 9 || {{{CIRCUIT_PURPOSE_C_ESTABLISH_REND}}} || "Hidden service client:
Establishing rendezvous point" ||
|| 10 || {{{CIRCUIT_PURPOSE_C_REND_READY}}} || "Hidden service client:
Pending rendezvous point" ||
|| 11 || {{{CIRCUIT_PURPOSE_C_REND_READY_INTRO_ACKED}}} || "Hidden service
client: Pending rendezvous point (ack received)" ||
|| 13 || {{{CIRCUIT_PURPOSE_C_MEASURE_TIMEOUT}}} || "Measuring circuit
timeout" ||
We can conclude from the state transitions that circuits are not in fact
"freed" when they are in transition state 7
({{{CIRCUIT_PURPOSE_C_INTRODUCE_ACK_WAIT}}}). In fact, all of our
circuits are actually in either state 8
({{{CIRCUIT_PURPOSE_C_INTRODUCE_ACKED}}}) or state 11
({{{CIRCUIT_PURPOSE_C_REND_READY_INTRO_ACKED}}}) instead. So, it is
therefore not sufficient to require them to be in state 7 when we are
reporting a timeout. We should also check for state 8.
If a circuit is reaped whilst in state 8, then it is also in a timeout
state worthy of reporting.
Therefore, suggest that we consider the following change:
{{{
--- circuitlist.c.orig 2018-04-30 23:02:07.322368461 +0000
+++ circuitlist.c 2018-04-30 23:03:01.721876917 +0000
@@ -2004,7 +2004,8 @@
orig_reason);
}
- if (circ->purpose == CIRCUIT_PURPOSE_C_INTRODUCE_ACK_WAIT) {
+ if (circ->purpose == CIRCUIT_PURPOSE_C_INTRODUCE_ACK_WAIT ||
+ circ->purpose == CIRCUIT_PURPOSE_C_INTRODUCE_ACKED) {
origin_circuit_t *ocirc = TO_ORIGIN_CIRCUIT(circ);
int timed_out = (reason == END_CIRC_REASON_TIMEOUT);
tor_assert(circ->state == CIRCUIT_STATE_OPEN);
}}}
What do you think?
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/25882#comment:13>
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