[tor-bugs] #23762 [Core Tor/Tor]: hs-v3: Client request with missing dirinfo will always timeout
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Oct 4 13:54:37 UTC 2017
#23762: hs-v3: Client request with missing dirinfo will always timeout
------------------------------+-----------------------------------------
Reporter: dgoulet | Owner: (none)
Type: defect | Status: new
Priority: High | Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor | Version:
Severity: Normal | Keywords: tor-hs, prop224, tor-client
Actual Points: | Parent ID:
Points: | Reviewer:
Sponsor: |
------------------------------+-----------------------------------------
When the SOCKS request is handled in `connection_ap_handle_onion()`, if we
are missing dirinfo (including missing a live consensus), the connection
state is put in "AP_CONN_STATE_CIRCUIT_WAIT".
Then it is retried every second through
`connection_ap_handshake_attach_circuit()` which does a gazillion things
but among those it tries to open the IP/RP circuits. Of course, we can't
get an IP because we have no descriptor so
`circuit_get_open_circ_or_launch()`, which tries to get that IP circuit,
won't be able so that function will get an intro point from the descriptor
(that doesn't exists because we can't even fetch it) but won't work.
It then triggers a descriptor fetch and then puts the connection in
`AP_CONN_STATE_RENDDESC_WAIT`. Now, because we don't look at the returned
code, we don't know what really happened and if tor still doesn't have
enough dirinfo to proceed, the connection is still put in "renddesc wait"
making it NOT a pending connection anymore thus never retried after that.
The only way for a connection to get out of that "renddesc wait" state is
either timing out (which is what happens for v3) or the descriptor arrives
and then there is a callback in the HS client subsystem to handle that
desc.
The possible solutions are I believe:
1. Either we keep the connection in "circuit wait" so it gets retried
regularly.
2. We create a new "AP CONN" state that is "waiting for dirinfo" and then
when we get the live consensus or/and minimum dirinfo, we callback the HS
subsystem and look for SOCKS conn in that state.
This is not a problem v2 HS suffers because it only care about a
"reasonably live consensus".
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/23762>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list