Opened 2 years ago

Closed 23 months ago

#19642 closed enhancement (implemented)

Add a descriptor line for Single Onion Services

Reported by: teor Owned by: dgoulet
Priority: Medium Milestone: Tor: 0.3.0.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs, rsos, sos, prop224, proposal, TorCoreTeam201611
Cc: Actual Points:
Parent ID: Points: 0.5
Reviewer: Sponsor: SponsorR-can

Description (last modified by teor)

Some of the things we want to do with Single Onion Services (like #17945) only work if clients know they're connecting to a Single Onion Service.

But it's hard to add an extra line to the existing HS descriptor format.

So it would be great if we could make this change when we implement the prop224 descriptor format.

Child Tickets

Change History (32)

comment:1 Changed 2 years ago by teor

Description: modified (diff)

comment:2 Changed 2 years ago by dgoulet

Keywords: prop224 added
Sponsor: SponsorR-can

This _only_ looks like a prop224 change so maybe we should make it child of #17238 instead which will make this ticket only a proposal change because #18571 and #18572 will then simply implement what's in the proposal.

comment:3 Changed 2 years ago by teor

Parent ID: #17945#17238

comment:4 Changed 2 years ago by teor

When a single onion service is on IPv6-only, it needs a rendezvous point that is IPv6-capable (with an IPv6-ORPort). So I also want single onion services to be able to put an attribute on the single onion service line, that asks for an IPv6-capable rend point.

For example:
direct-connection ipv6

This way, clients know to supply an IPv6 rendezvous point, and Tor2web knows to make a 3-hop connection.

comment:5 Changed 2 years ago by teor

And when Tor2web gets a descriptor with a direct-connection line, it needs to connect using a 3-hop path to the intro and rendezvous.

Hmm. Maybe we should call it: client-must-multi-hop instead?

Last edited 2 years ago by teor (previous) (diff)

comment:6 Changed 2 years ago by dgoulet

Keywords: TorCoreTeam201608 added

comment:7 Changed 2 years ago by dgoulet

Owner: set to dgoulet
Status: newaccepted

The plan is to merge HSDir support in 029 which is almost ready (#17238). However, this line would go in the encrypted section of the descriptor meaning only the client/service will use it which will come not until 030 at the earliest so I propose we think more about this option and do no press on for 029. Keep in mind that Tor2web will not be implemented as part of prop224 so this should only apply to RSOS/SOS.

Anycase, we need a proposal change before code can be fixed.

comment:8 Changed 2 years ago by dgoulet

Keywords: TorCoreTeam201609 added; TorCoreTeam201608 removed

Review and merge will happen in September.

comment:9 Changed 2 years ago by teor

There's a further complication here:

  • Tor hidden services only send an intro IPv4 extend info as part of the hidden service descriptor, so there's no way for the client to know the intro IPv6 address to connect to
  • Tor clients only send an IPv4 extend info for the rend point as part of the INTRODUCE cell, so there's no way for the service to know the rend IPv6 address to connect to

We really should send both IPv4 and IPv6 addresses as part of the proposal, if we don't do this already.

comment:10 Changed 2 years ago by teor

We do encode both IPv4 and IPv6 addresses in the prop224 descriptor, and #17178 has single onion services retry a multi-hop path if the single-hop path is unreachable. #19662 will do the same thing for Tor2web. And #19745 will block

So we can get the desired behaviour without a proposal change:

  • Tor2web always connects to HSDirs using a 3-hop path to avoid denial of service (#20104)
  • When a HSDir, intro, or rend might become a one-hop proxy, it refuses (#17945)
  • When Tor2web (#19662) or Single Onion Services (#19663) fail to connect, they retry with a 3-hop path

But this still gives the intro and rend point both the Tor2web and single onion service IP addresses, even if they don't successfully connect.

So the remaining work in this ticket is:

  • a single onion service must put a "client-must-multi-hop" line in the unencrypted part HS descriptor
  • all clients must multi-hop to HSDirs, intro points and rend points with this line in their descriptors:
    • the HSDir must refuse to serve descriptors with this line to Tor2web clients (this will block Tor2web to Single Onion Services until Tor2web clients upgrade to #20104 - is this a good idea?)
    • HSDir, intro and rend also refuse connections with non-relays on both sides

This prevents HSDir, intro and rend points knowing both sides' IP addresses, and reduces connection failures (except in the Tor2web HSDir case).

comment:11 Changed 2 years ago by dgoulet

Status: acceptedneeds_information

We have no plans of supporting Tor2Web in prop224 so here I would simply add a line in the descriptor saying "I'm RSOS" for now.

I like the direct-connection ipv6 but kind of fear it because this makes a client pick a subset of RP (IPv6) so I'm kind of concerned about the partition "attack" problem but yet if the service is only IPv6, we need something that tells the client to pick a valid RP... Maybe there are enough nodes nowadays that have both v4 and v6 that partition is not really an issue?

comment:12 Changed 2 years ago by asn

Milestone: Tor: 0.2.???Tor: 0.3.0.x-final

Triaging here.

I think we should aim to implement this for 0.3.0. Ideally we would even get it in 0.2.9 along with the main RSOS code, but the ship has sailed.

I'm also not sure how this direct-connection/IPv6 stuff ended up sneaking into this ticket. Shouldn't that be a different ticket?

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

Replying to asn:

Triaging here.

I think we should aim to implement this for 0.3.0. Ideally we would even get it in 0.2.9 along with the main RSOS code, but the ship has sailed.

I'm also not sure how this direct-connection/IPv6 stuff ended up sneaking into this ticket. Shouldn't that be a different ticket?

It's unnecessary - we fixed it on the single onion service side by making the single onion service connect to known unreachable RPs over a 3-hop path, and reconnect on RP connection failure over a 3-hop path.

comment:14 Changed 2 years ago by dgoulet

Ok so only direct-connection flag is enough then? If so, I'll make a spec patch for it.

comment:15 Changed 2 years ago by asn

Nitpicking: do we actually want to call it direct-connection? Isn't that too vague/general?

Why not single-onion-service?

comment:16 in reply to:  15 Changed 2 years ago by dgoulet

Replying to asn:

Nitpicking: do we actually want to call it direct-connection? Isn't that too vague/general?

Why not single-onion-service?

+1

comment:17 Changed 2 years ago by teor

Status: needs_informationneeds_revision

Whatever we call it, here's what I think it means:

The service is a single onion service. It may make direct connections to introduction and rendezvous points. Clients should make 3-hop connections to introduction and rendezvous points, to avoid having their connections blocked by upcoming relay defenses against one-hop hidden service proxies.

I am happy to use single-onion-service, as I think it's unlikely we'll implement prop 252-style services (services that extend to an ORPort), and if we do, they will have their own link specifier type and semantics, distinct from single onion services as now implemented.

comment:18 Changed 2 years ago by dgoulet

Keywords: TorCoreTeam201610 proposal added; 030-proposed TorCoreTeam201609 removed
Status: needs_revisionneeds_review

Ok simple patch, see ticket19642_01

comment:19 in reply to:  18 Changed 2 years ago by asn

Replying to dgoulet:

Ok simple patch, see ticket19642_01

torspec branch looks good to me. I guess next step is the tor patch?

comment:20 Changed 2 years ago by dgoulet

1) Do we want to do it for current v2 HS version?

Personally, I don't think we need this for v2 as the improvement that this line will give us is more on the UI/UX side of TBB for instance which could take a while to get in and by that point will have prop224 not far from done.

Also, we would have to make _sure_ that clients won't explode with an unknown line in the descriptor and HSDir will also accept it as they do parse the descriptor for validation.

2) Once #17238 is merged, we do the prop224 code for this but before we can't really do anything.

comment:21 in reply to:  20 Changed 2 years ago by teor

Replying to dgoulet:

1) Do we want to do it for current v2 HS version?

Personally, I don't think we need this for v2 as the improvement that this line will give us is more on the UI/UX side of TBB for instance which could take a while to get in and by that point will have prop224 not far from done.

I can't see any direct benefit from this, as we are not doing the relay-side mitigations in 0.3.0 as far as I know.

Also, we would have to make _sure_ that clients won't explode with an unknown line in the descriptor and HSDir will also accept it as they do parse the descriptor for validation.

I don't think it's worth the risk.

comment:22 Changed 2 years ago by asn

Status: needs_reviewnew

(Switching this to new as tor.git patch is also required)

comment:23 Changed 2 years ago by dgoulet

Keywords: TorCoreTeam201611 added; TorCoreTeam201610 removed

comment:24 Changed 2 years ago by nickm

Suggestion for the torspec patch: Add a sentence like "Older versions of the Single Onion Service implementation did not include this line."

comment:25 Changed 23 months ago by dgoulet

Parent ID: #17238
Status: newaccepted

Now that #17238 is merged, un-parenting so we can do this one independently.

comment:26 Changed 23 months ago by dgoulet

Ok, I've added nickm's suggestion clarifying that this will be for onion service >= 0.3.0 as I'm about to work on the patch for inclusion in 030.

If no objection, I'll merge this branch to torspec: ticket19642_01

comment:27 Changed 23 months ago by dgoulet

Status: acceptedneeds_review

Tor patch: ticket19642_030_01
Spec patch: ticket19642_01

comment:28 in reply to:  27 ; Changed 23 months ago by teor

Status: needs_reviewneeds_revision

Replying to dgoulet:

Tor patch: ticket19642_030_01

If rend_service_non_anonymous_mode_enabled() is true, we should set desc->encrypted_data.single_onion_service to 1.

Spec patch: ticket19642_01

Looks good.

comment:29 in reply to:  28 Changed 23 months ago by dgoulet

Status: needs_revisionneeds_review

Replying to teor:

Replying to dgoulet:

Tor patch: ticket19642_030_01

If rend_service_non_anonymous_mode_enabled() is true, we should set desc->encrypted_data.single_onion_service to 1.

This patch is about HS descriptor support, not service side for v3 protocol so there is no place we can actually do such a thing right now. It will come with service side implementation.

Spec patch: ticket19642_01

Looks good.

comment:30 Changed 23 months ago by teor

Ah right, let's get it merged, then.

comment:31 Changed 23 months ago by teor

Status: needs_reviewmerge_ready

comment:32 Changed 23 months ago by nickm

Resolution: implemented
Status: merge_readyclosed

ok, merging.

Note: See TracTickets for help on using tickets.