hs: Stop intro points being used as single hop proxies
This prevents them knowing both the service and client IP addresses, and therefore being targets for network traffic logging, sybil, or hacking attacks.
We need to implement the following checks:
- if an introduction point was made using a direct connection (single onion services), refuse direct client connections,
- for v3 intro points, always refuse direct client connections
- for v2 intro points, refuse direct client connections based on a consensus parameter
if the rend point was made using a direct connection (custom client, no tor2web for HSv3), refuse direct service connections (single onion services).
See #22688 (moved) for how this is done for HSDir3s using channel_is_client(). The comments in that patch explain why it works.
We could even refactor the common code out of connection_dir_is_anonymous() into connection_is_anonymous(), and avoid including channel[tls].h into directory.c.
I'm not sure if I will get time to do this, so please feel free to take this ticket.
Activity
changed milestone to %Tor: unspecified
We can do this for HSv2 rend points when we implement this patch, because single onion services retry a 3-hop path on failure.
But we can't fix HSv2 intro points, because tor2web doesn't retry a 3-hop path (#19662 (moved)).
See cddff59c0 in my branch bug22688-031 for code that might work for OR circuits. (I accidentally wrote the OR version rather than the directory version.)
Trac:
Description: This prevents them knowing both the service and client IP addresses, and therefore being targets for network traffic logging, sybil, or hacking attacks.We need to implement the following checks:
- if the introduction point was made using a direct connection (single onion services), refuse direct client connections,
- if the rend point was made using a direct connection (custom client, no tor2web for HSv3), refuse direct service connections (single onion services).
See #22668 (moved) for how this is done for HSDir3s using channel_is_client(). The comments in that patch explain why it works.
We could even refactor the common code out of connection_dir_is_anonymous() into connection_is_anonymous(), and avoid including channel[tls].h into directory.c.
I'm not sure if I will get time to do this, so please feel free to take this ticket.
to
This prevents them knowing both the service and client IP addresses, and therefore being targets for network traffic logging, sybil, or hacking attacks.
We need to implement the following checks:
- if the introduction point was made using a direct connection (single onion services), refuse direct client connections,
- if the rend point was made using a direct connection (custom client, no tor2web for HSv3), refuse direct service connections (single onion services).
See #22688 (moved) for how this is done for HSDir3s using channel_is_client(). The comments in that patch explain why it works.
We could even refactor the common code out of connection_dir_is_anonymous() into connection_is_anonymous(), and avoid including channel[tls].h into directory.c.
I'm not sure if I will get time to do this, so please feel free to take this ticket.
Status: new to needs_revisionLatest code in #17945 (moved)
Trac:
Status: needs_revision to needs_review
Changing ticket title to reflect that it now applies to all HS version. Then moving it to 033 and I'm taking it, I'll submit a branch soon. We are splitting things out of #17945 (moved) so we don't get too confused.
Trac:
Status: needs_review to assigned
Summary: prop224: Stop rend and intro points being used as single hop proxies to hs: Stop rend and intro points being used as single hop proxies
Owner: teor to dgoulet
Milestone: Tor: 0.3.4.x-final to Tor: 0.3.3.x-final
Keywords: prop224 deleted, N/A addedI'll review this later today, after I get some Rust done.
Do we want a consensus parameter to block Tor2web at Intros, like the one at Rendezvous? I think the answer is "yes, but not on by default, and not on right now, and maybe just in 0.3.4". I opened #25371 (moved) to do it in a separate task.
Trac:
Reviewer: N/A to teor-
Replying to teor:
I'll review this later today, after I get some Rust done.
Do we want a consensus parameter to block Tor2web at Intros, like the one at Rendezvous? I think the answer is "yes, but not on by default, and not on right now, and maybe just in 0.3.4". I opened #25371 (moved) to do it in a separate task.
Yes I think ultimately (hopefully 034 imo), we come down to rejecting single hop client for any part of the HS dance (single onion or not). Lets open a ticket for that at the RDV?
I've modified the branch based on asn's comment to merge the suitable functions into one. I've renamed the function also to reflect a bit more what it is doing.
See fixup
216c754e6f. -
Replying to asn:
Are we sure this is not gonna make single onion services (and tor2web clients) go crazy with reconnecting and end up hurting the network?
In theory, because the circuits are closed at the RP with the "TORPROTOCOL" reason, the client should pick a new rendezvous point. However, there is a good chance the tor2web client will just loop over all RPs it can find and try them all in a loop. That would need to be tested.
v2 Intro:
v2 Tor2web will extend to another intro point, and then succeed because it's no longer a single hop path.
v2 Rendezvous:
v2 single onion services retry failed rendezvous with a 3-hop path, so they should retry once. But we turned off retries to try to reduce the DDoS load. So I guess they will just fail. And then v2 Tor2web will try another rendezvous point, and eventually give up. But we turned off Tor2web at rendezvous points.
So we should use one of these combination of rendezvous retry and Tor2web settings in the consensus:
- banning Tor2web works, or
- allowing Tor2web and at least 1 retry also works.
But allowing Tor2web and with no retries will put extra load on the network from Tor2web / single onion service failures.
v3:
We never implemented any special retry behaviour for v3 single onion services, but that doesn't matter, because there is no v3 Tor2web.
Replying to teor:
v2 Intro:
v2 Tor2web will extend to another intro point, and then succeed because it's no longer a single hop path.
The client will only extend if it thinks that the service isn't connected to the intro point. So maybe we shouldn't close intro circuits, but we should force them to extend instead?
And then we can have an option for closing them as a DDoS defence.
-
Replying to teor:
Replying to teor:
v2 Intro:
v2 Tor2web will extend to another intro point, and then succeed because it's no longer a single hop path.
The client will only extend if it thinks that the service isn't connected to the intro point. So maybe we shouldn't close intro circuits, but we should force them to extend instead?
In theory, just a NACK received by the client will make it reuse the circuit and re-extend. See
handle_introduce_ack(). This patch makes the intro returnHS_CELL_INTRO_ACK_NORELAYwhich triggers a re-extend. Same goes for v2 inrend_client_introduction_acked().
