Add a descriptor line for Single Onion Services

Some of the things we want to do with Single Onion Services (like #17945 (moved)) 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.

changed milestone to %Tor: 0.3.0.x-final

added TorCoreTeam201611 component::core tor/tor milestone::Tor: 0.3.0.x-final owner::dgoulet points::0.5 priority::medium prop224 proposal resolution::implemented rsos severity::normal sos sponsor::R-can status::closed tor-hs type::enhancement labels

Trac:
Description: Some of the things we want to do with Single Onion Services (like #17945 (moved)) 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 prop #224 (closed) descriptor format.

to

Some of the things we want to do with Single Onion Services (like #17945 (moved)) 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.

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

Trac:
Sponsor: N/A to SponsorR-can
Keywords: N/A deleted, prop224 added

Trac:
Parent: #17945 (moved) to #17238 (moved)

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.

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?

Trac:
Keywords: N/A deleted, TorCoreTeam201608 added

The plan is to merge HSDir support in 029 which is almost ready (#17238 (moved)). 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.

Trac:
Status: new to accepted
Owner: N/A to dgoulet

Review and merge will happen in September.

Trac:
Keywords: TorCoreTeam201608 deleted, TorCoreTeam201609 added

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.

We do encode both IPv4 and IPv6 addresses in the prop224 descriptor, and #17178 (moved) has single onion services retry a multi-hop path if the single-hop path is unreachable. #19662 (moved) will do the same thing for Tor2web. And #19745 (moved) 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 (moved))
• When a HSDir, intro, or rend might become a one-hop proxy, it refuses (#17945 (moved))
• When Tor2web (#19662 (moved)) or Single Onion Services (#19663 (moved)) 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 (moved) - 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).

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?

Trac:
Status: accepted to needs_information

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?

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

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.

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

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

Why not single-onion-service?

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

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.

Trac:
Status: needs_information to needs_revision

Ok simple patch, see ticket19642_01

Trac:
Keywords: 030-proposed, TorCoreTeam201609 deleted, proposal, TorCoreTeam201610 added
Status: needs_revision to needs_review

Replying to dgoulet:

Ok simple patch, see ticket19642_01

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

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 (moved) is merged, we do the prop224 code for this but before we can't really do anything.

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.

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

Trac:
Status: needs_review to new

Trac:
Keywords: TorCoreTeam201610 deleted, TorCoreTeam201611 added

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

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

Trac:
Parent: #17238 (moved) to N/A
Status: new to accepted

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

Tor patch: ticket19642_030_01 Spec patch: ticket19642_01

Trac:
Status: accepted to needs_review

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.

Trac:
Status: needs_review to needs_revision

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.

Trac:
Status: needs_revision to needs_review

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

Trac:
Status: needs_review to merge_ready

ok, merging.

Trac:
Resolution: N/A to implemented
Status: merge_ready to closed

closed

changed time estimate to 4h

mentioned in issue #32571 (moved)

moved to tpo/core/tor#19642 (closed)

mentioned in issue tpo/applications/tor-browser#32571 (closed)