Opened 2 years ago

Last modified 10 days ago

#17945 accepted enhancement

Stop single hop client connecting to (Rendezvous) Single Onion Services

Reported by: teor Owned by: dgoulet
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor2web, tor-hs, 029-proposed, 029-teor-no, needs-design, needs-proposal-maybe, single-onion, review-group-33, 034-triage-20180328, 034-removed-20180328
Cc: Actual Points: 0.4
Parent ID: #24962 Points: 5
Reviewer: asn, teor Sponsor:

Description

Tor2Web clients make a one-hop connection to the rendezvous point. Rendezvous Single Onion Services also make a one-hop connection to the rendezvous point. (Single Onion Services expect a client to make an extend request to the Single Onion Service at the end of a 3-hop path.)

This uses Tor as a one-hop proxy (in this case, to a single onion service), which we try to avoid, because it enables certain attacks.

For Rendezvous Single Onion Services, I don't know how to prevent this happening. (Should the rendezvous point intervene? Should we add something to the RSOS descriptor?)

For Single Onion Services, we can modify the Tor2Web client code so it doesn't make the SOS extend request, but falls back to rendezvous mode.

Child Tickets

TicketTypeStatusOwnerSummary
#19662defectclosedOn intro failure, Tor2web should build a 3-hop path
#20104defectclosedTor2web should connect to HSDirs over a 3-hop path
#22688defectneeds_revisionteorhs: Make sure HSDir never know service, client, or bridge IP addresses
#22689defectneeds_revisiondgouleths: Stop rend and intro points being used as single hop proxies
#25371enhancementassignedteorAdd a consensus parameter for blocking single hop client intro

Change History (57)

comment:1 in reply to:  description ; Changed 2 years ago by teor

Keywords: tor2web added

Replying to teor:

Tor2Web clients make a one-hop connection to the rendezvous point. Rendezvous Single Onion Services also make a one-hop connection to the rendezvous point. (Single Onion Services expect a client to make an extend request to the Single Onion Service at the end of a 3-hop path.)
...
For Rendezvous Single Onion Services, I don't know how to prevent this happening. (Should the rendezvous point intervene? Should we add something to the RSOS descriptor?)

The rendezvous point (and possibly the introduction point) could terminate the connection if it has a single hop on both ends. This seems to be the most correct option.

RSOS descriptors could claim to be a RSOS, and then Tor2web can avoid connecting to the RSOS. But this provides a generic method for hidden services to block Tor2web. I'm not sure we want that, and I don't know if all Tor2web operators would enable the feature.

comment:2 Changed 2 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.9.x-final

It is impossible that we will fix all 226 currently open 028 tickets before 028 releases. Time to move some out. This is my second pass through the "new" and tickets, looking for things to move to 0.2.9.

comment:3 Changed 2 years ago by teor

Parent ID: #17178

In #18082, we may have Rendezvous Single Onion Services add an identifying line to their descriptors,so we could measure their HSDir statistics separately.

If we identify RSOS in their descriptor, then we can make sure Tor2web clients don't connect to them (#17945).

I'll look at this again in 0.2.9.

comment:4 Changed 2 years ago by teor

This can be done by blocking the X-Tor2web header, as detailed here:
https://lists.torproject.org/pipermail/tor-onions/2016-February/000050.html

comment:5 Changed 2 years ago by asn

Keywords: tor-hs added
Points: small/medium

comment:6 Changed 2 years ago by isabela

Milestone: Tor: 0.2.9.x-finalTor: 0.2.???

tickets market to be removed from milestone 029

comment:7 Changed 2 years ago by teor

This was raised on the tor-project mailing list, and I said:

We'e yet to arrive at a mechanism to make this happen, but I think we will end up adding a line to the onion service descriptor.
We could make this a configuration parameter (AllowTor2Web?) that defaults to 1 for hidden services, and 0 for single onion services.

https://lists.torproject.org/pipermail/tor-project/2016-May/000333.html

comment:8 in reply to:  1 ; Changed 2 years ago by teor

Replying to teor:

Replying to teor:

Tor2Web clients make a one-hop connection to the rendezvous point. Rendezvous Single Onion Services also make a one-hop connection to the rendezvous point. (Single Onion Services expect a client to make an extend request to the Single Onion Service at the end of a 3-hop path.)

The rendezvous point (and possibly the introduction point) could terminate the connection if it has a single hop on both ends. This seems to be the most correct option.

This could result in false positives if the consensus gets out of sync.
Or is there a reliable way for a relay to detect non-relays without using the consensus?
(How does the padding do it?)

comment:9 in reply to:  8 Changed 2 years ago by teor

Replying to teor:

Replying to teor:

Replying to teor:

Tor2Web clients make a one-hop connection to the rendezvous point. Rendezvous Single Onion Services also make a one-hop connection to the rendezvous point. (Single Onion Services expect a client to make an extend request to the Single Onion Service at the end of a 3-hop path.)

The rendezvous point (and possibly the introduction point) could terminate the connection if it has a single hop on both ends. This seems to be the most correct option.

This could result in false positives if the consensus gets out of sync.
Or is there a reliable way for a relay to detect non-relays without using the consensus?
(How does the padding do it?)

arma says on tor-project@ that we can do it the same way exits do it - by aggressively fetching the consensus from the authorities. (Fortunately, fallback directories in 0.2.8 will reduce the client load on authorities, allowing relays scope to do this.)

Then we can teach single onion services to advertise their single-hop nature in their descriptors, and tor2web and similar clients to build multi-hop paths to intro and rendezvous points for those services.

comment:10 Changed 2 years ago by nickm

Keywords: 029-proposed added

comment:11 Changed 2 years ago by virgil

Then we can teach single onion services to advertise their single-hop nature in their descriptors, and tor2web and similar clients to build multi-hop paths to intro and rendezvous points for those services.

Totally support this solution. If clients can detect which domains are single-onion services then tor2web-mode can be made to simply add an another hop for those domains. Seems solid to me.

comment:12 Changed 2 years ago by cypherpunks

What would be best is a way to keep tor2web mode clients from connecting to one's HS at all.

comment:13 in reply to:  12 Changed 2 years ago by teor

Replying to cypherpunks:

What would be best is a way to keep tor2web mode clients from connecting to one's HS at all.

Some tor2web clients set the x-tor2web: true HTTP header.

This isn't a protool-agnostic solution by any means, and it still involves exchanging some data with those clients.
https://lists.torproject.org/pipermail/tor-project/2016-May/000362.html

comment:14 Changed 2 years ago by nickm

Keywords: 029-nickm-unsure added

comment:15 Changed 2 years ago by teor

Keywords: 029-teor-yes added
Owner: set to teor
Status: newassigned

comment:16 Changed 22 months ago by teor

Keywords: TorCoreTeam201607 added
Points: small/medium2

comment:17 Changed 22 months ago by virgil

Then we can teach single onion services to advertise their single-hop nature in their descriptors, and tor2web and similar clients to build multi-hop paths to intro and rendezvous points for those services.

Following up on the above---minimizing the RP's juiciness to attack is definitely a good idea. This solution above is the best solution I've heard.

comment:18 Changed 22 months ago by teor

Keywords: 029-teor-no needs-design needs-proposal-maybe added; 029-teor-yes TorCoreTeam201607 removed
Points: 25
Status: assignedneeds_information

There are three different but related issues here. We have a design that fixes them, but there are some drawbacks. So this needs some more design work, and perhaps a proposal.

Stop Tor2web connecting to Single Onion Services:

Relays should avoid being the only relay in a circuit between Tor2web and a Single Onion Service - so it isn't in a position to de-anonymise both client and service (this discourages attacks)

  • intro points and rend points should require one or both sides of the connection to be in the consensus
    • this has load-balancing issues, as the way exits check for relays is to fetch consensuses from the authorities
      • do we want all relays to have to fetch from authorities? Maybe 7000 relays is not a big issue
      • maybe we could use the solution that netflow padding uses?
  • teach Tor2web to build a 3?-hop path to a single onion service to avoid being blocked by this feature
    • this may have compatibility issues with older versions, because we need to mark single onion service descriptors as coming from a single onion service, so Tor2web knows to build a longer path, but older clients / HSDirs might not be able to parse descriptors with extra fields

Stop clients sending arbitrary Rendezvous points to Single Onion Services:

  • teach single onion services to check that the rendezvous point is in the consensus
    • what if we want to allow this as a feature? (have a per-service "unsafe" option?)
    • this has load-balancing issues, as the way exits check for relays is to fetch consensuses from the authorities
      • do we want all single onion services to have to fetch from authorities? If they become popular, this could create a huge load on the authorities (what if someone launches 1000 single onion service instances?)
      • maybe we could use the solution that netflow padding uses?
  • are arbitrary rendezvous points a significant issue for a non-anonymous service?

Stop hidden services sending arbitrary Intro points to Tor2web:

  • teach Tor2web to check that the intro point is in the consensus
    • this has load-balancing issues, as the way exits do this is to fetch consensuses from the authorities
      • do we want all Tor2web clients to have to fetch from authorities? Is Tor2web that popular already? This could inadvertently create a huge load on the authorities
      • maybe we could use the solution that netflow padding uses?
  • are arbitrary intro points a significant issue for a non-anonymous client?

comment:19 Changed 22 months ago by teor

Split off #19662 and #19663 so that Tor2web and Single Onions build 3-hop paths on failure.
Split off #19642 so that Single Onions tell Tor2web to use a 3-hop path to the intro and rendezvous.

So the work remaining in this ticket is:

  • Relays should avoid being the only relay in a circuit between Tor2web and a Single Onion Service - so it isn't in a position to de-anonymise both client and service (this discourages attacks)
    • intro points and rend points should require one or both sides of the connection to be in the consensus

I think it's ok for the intro and rend points to just use the consensus they have right now, even if it's a bit outdated. It's unlikely that both sides of a client to HS connection will be new in the consensus. Occasionally there will be a false positive on Tor2web to HS or client to Single Onion connections (but the retry will fix that).

comment:20 Changed 20 months ago by teor

We should do this for HSDirs as well. If the upload came directly (a custom tor version - Single Onion Services use a 3-hop path), they should refuse direct downloads (Tor2web does direct downloads, but we want to fix this in #20104).

But do we really want to store this information on HSDirs?

comment:21 Changed 20 months ago by teor

Status: needs_informationnew

comment:22 Changed 19 months ago by nickm

Keywords: 029-nickm-says-no added

comment:23 Changed 17 months ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:24 Changed 16 months ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:25 Changed 11 months ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:26 Changed 11 months ago by nickm

Keywords: 029-nickm-says-no removed

comment:27 Changed 11 months ago by nickm

Keywords: 029-nickm-unsure removed

comment:28 in reply to:  20 Changed 10 months ago by teor

Replying to teor:

We should do this for HSDirs as well. If the upload came directly (a custom tor version - Single Onion Services use a 3-hop path), they should refuse direct downloads (Tor2web does direct downloads, but we want to fix this in #20104).

But do we really want to store this information on HSDirs?

#22688 fixes this issue for HSv3 by rejecting direct descriptor uploads and downloads.

#22689 will fix this for rend and intro points for HSv3.

So we can close this ticket once they are done and we have deprecated HSv2.

Last edited 10 months ago by teor (previous) (diff)

comment:29 Changed 10 months ago by nickm

Milestone: Tor: unspecifiedTor: 0.3.2.x-final

comment:30 Changed 10 months ago by teor

Keywords: single-onion added; rsos removed

Now there's only one kind of single onion service, change rsos to single-onion

comment:31 Changed 10 months ago by teor

Keywords: sos removed

Now there's only one kind of single onion service, remove all references to old sos tag

comment:32 Changed 7 months ago by teor

Milestone: Tor: 0.3.2.x-finalTor: 0.3.3.x-final

I'm not going to get time to do these in 0.3.2.
Moving them to 0.3.3.

comment:33 Changed 4 months ago by teor

Owner: teor deleted
Status: newassigned

Disowning tickets I don't intend to work on in the next 6 months.

comment:34 Changed 4 months ago by teor

Status: assignednew

Mark all tickets that are assigned to nobody as "new".

comment:35 Changed 3 months ago by dgoulet

Parent ID: #24962

comment:36 Changed 2 months ago by dgoulet

Status: newneeds_information

Ticket #24902 adds an option to refuse establish rdv from single hop client.

I think we can extend this to relays that is if the previous and next hop in a rendezvous circuit are unauthenticated that is client connection, the circuit collapses.

I'm just wondering here the bridge factor. I guess even if a SOS is configured to use a bridge (is it even possible?), it would require a client to single hop through a bridge for the RP to deny it. And maybe we don't care with such a crazy setup?

comment:37 Changed 2 months ago by teor

Status: needs_informationnew

It is not possible for Tor2web or single onion services to use a bridge. They do not use entry guards. (I don't know what happens when you try. Don't expect it to work.)

We should fix this issue on relays by refusing to rend splice a direct client to another direct client. And similar for intros. For rend and intro v3, see #22689. For HSDir v3, see #22688.

Not sure where the v2 tickets got to.

comment:38 Changed 2 months ago by asn

Sorry for being pessimistic here, but do we think this is really worth the effort?

IIUC this ticket is meant to protect tor2web clients who connect to single onions. Do we think there are actual tor2web clients who care to be protected? My understanding is that all tor2web clients are just onion.to-type of services and I bet they don't care about their anonymity. If an actual person went through all the effort to compile their Tor into tor2web mode and then configured their browser to use that, I bet they kinda know what's going on. What's the class of people we are trying to protect here, and is it worth going through all that effort?

Or are we doing just that to demotivate attackers from camping into RPs? What kind of attackers would do that if they understood the above?

Sorry if I'm misunderstanding something but the top-post is quite vague in its attacks description, so I'm not sure I'm up to date here. Thanks!

comment:39 in reply to:  38 Changed 2 months ago by teor

Replying to asn:

Sorry for being pessimistic here, but do we think this is really worth the effort?

IIUC this ticket is meant to protect tor2web clients who connect to single onions.

No, it's meant to protect relays from knowing both client and service IP addresses. And it's meant to protect relays from being turned into single-hop proxies. It's like the single-hop exit ban.

Do we think there are actual tor2web clients who care to be protected? My understanding is that all tor2web clients are just onion.to-type of services and I bet they don't care about their anonymity.

Some of them are automated hidden service scanners, too.

If an actual person went through all the effort to compile their Tor into tor2web mode and then configured their browser to use that, I bet they kinda know what's going on. What's the class of people we are trying to protect here, and is it worth going through all that effort?

Relay operators from attacks or legal threats, and relays from DDoS or overload.

comment:40 Changed 2 months ago by dgoulet

So I think in theory this should be simple. Once we splice the rend circuit, we should asses that the p_chan *and* the n_chan are both clients (channel_is_client()). If so, we close both circuits with a remote reason.

Either we go with END_CIRC_REASON_TORPROTOCOL but then we have to bake it in the tor spec I think that we don't allow both ways to be single hop. Or something like END_CIRC_REASON_DESTROYED... I think we just need a reason that will make the tor2web client not retry again and again the same RP.

Last edited 2 months ago by dgoulet (previous) (diff)

comment:41 Changed 2 months ago by dgoulet

Owner: set to dgoulet
Status: newaccepted

I think the patch would simply looks like this. Nothing final, I just want feedback.

Branch: ticket17945_033_01

comment:42 Changed 2 months ago by dgoulet

Status: acceptedneeds_review

comment:43 Changed 2 months ago by nickm

Keywords: review-group-33 added

comment:44 Changed 2 months ago by asn

Reviewer: asn

comment:45 Changed 2 months ago by teor

Reviewer: asnasn, teor

comment:46 in reply to:  41 Changed 8 weeks ago by asn

Replying to dgoulet:

I think the patch would simply looks like this. Nothing final, I just want feedback.

Branch: ticket17945_033_01

I guess that looks simple and decent enough. Is it guaranteed that p_chan will exist for those circuits? Should we check the existence of those p_chans before we call channel_is_client() on them? Other than that, LGTM.

comment:47 Changed 8 weeks ago by teor

Status: needs_reviewneeds_revision

Good catch!

There should be no way we can get to this code without a p_chan, because both circuits needed a p_chan at some point in the past to establish a rendezvous. But we could accidentally add a bug like this in future.

If either circuit doesn't have a p_chan (because it's just been closed), the rendezvous should fail.
So we should do the p_chan check and fail, because channel_is_client() hard asserts on NULL channels.

Do you think we should BUG() if either p_chan is NULL?
I'm not sure, because channels can close by themselves, and I'm not sure if they clean up all their circuits straight away.

comment:48 Changed 8 weeks ago by teor

Also, can we do the whole HS protocol at once:

  • intro point v2 and v3: close the HS INTRODUCE side if both sides are directly connected (#22689)
  • HS v2: refuse descriptor uploads if the service is directly connected (#22688)
    • we can't refuse direct descriptor downloads, because Tor2web uses them
  • HSv3: refuse descriptor uploads and downloads if the client or service are directly connected (#22688)

I'll see if I can do these in 15 minutes,

comment:49 Changed 8 weeks ago by teor

Replying to teor:

Also, can we do the whole HS protocol at once:

  • intro point v2 and v3: close the HS INTRODUCE side if both sides are directly connected (#22689)
  • HS v2: refuse descriptor uploads if the service is directly connected (#22688)
    • we can't refuse direct descriptor downloads, because Tor2web uses them
  • HSv3: refuse descriptor uploads and downloads if the client or service are directly connected (#22688)

My branch bug-22688-22689-033-v2 on https://github.com/teor2345/tor.git has HSDir and intro single-hop rejects. And it makes the unit tests work.

It doesn't have dgoulet's rendezvous fixes. dgoulet might want to copy my p_chan checks, and unit test fixes :-)

We should merge the branches together when we're done, and add a changes file.

I'll see if I can do these in 15 minutes

Nope, 180 minutes. I should multiply all my estimates by 12.

comment:50 Changed 8 weeks ago by teor

Actual Points: 0.4

comment:51 in reply to:  48 Changed 7 weeks ago by asn

Replying to teor:

Also, can we do the whole HS protocol at once:

  • intro point v2 and v3: close the HS INTRODUCE side if both sides are directly connected (#22689)
  • HS v2: refuse descriptor uploads if the service is directly connected (#22688)
    • we can't refuse direct descriptor downloads, because Tor2web uses them
  • HSv3: refuse descriptor uploads and downloads if the client or service are directly connected (#22688)

Hmmm. Kinda naughty to dump all this so late in the process. I don't think this can be 033 material, but perhaps we could consider it for 034. I liked dgoulet's patch because it was super simple and did the thing, but this new patchset is too complicated IMO.

Particularly commit 10290066c8 and connection_dir_is_anonymous() is way more complicated than anything I would hope to see in this ticket. It's untestable, requires super deep knowledge of Tor's internals and is called by multiple dir entry points...

My suggestion is to go with something simple for now (maybe dgoulet's branch or nothing at all) if we want to go for 033, and then in Rome we should try to think hard of how exactly we want to treat and support 1-hop clients/services, and design the appropriate patchsets with calm.

comment:52 Changed 7 weeks ago by teor

I suggest we deal with rend in 0.3.3, because it's the greatest risk.
Or, we could deal with rend and intro in 0.3.3 if we wanted.

I am happy leaving HSDir for 0.3.4.

comment:53 Changed 7 weeks ago by dgoulet

Milestone: Tor: 0.3.3.x-finalTor: 0.3.4.x-final
Status: needs_revisionaccepted

I'm OK with rend and intro in 033. It is an easy fix because we can easily check the two circuits on both sides.

Agree on the HSDir part to be in 034 and we'll have to try to inject a bit more semantic in that function.

I'm putting back this in "Accepted", sending it to 034 and moving the patch for 033 in #22689

comment:54 Changed 7 weeks ago by dgoulet

Summary: Stop Tor2Web connecting to (Rendezvous) Single Onion ServicesStop single hop client connecting to (Rendezvous) Single Onion Services

Changing the title just to be a tiny bit more accurate about single hop client instead of just Tor2web.

comment:55 Changed 3 weeks ago by nickm

Keywords: 034-triage-20180328 added

comment:56 Changed 3 weeks ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:57 Changed 10 days ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

Note: See TracTickets for help on using tickets.