Rendezvous Single Onion Services: One-Hop Intro Point and Rendezvous

The following patch enables one-hop intro point and rendezvous connections for onion service servers. It is compatible with current tor clients and relays.

Use the following torrc lines to make intro point and rendezvous point connections one-hop on the server:

__OnionSrvIntroRouteLength 1
__OnionSrvRendRouteLength 0

Branch: hs-route-len-v2 Repository: https://github.com/teor2345/tor.git

changed milestone to %Tor: 0.2.9.x-final

added TorCoreTeam201609 actualpoints::14 component::core tor/tor milestone::Tor: 0.2.9.x-final owner::teor points::6.5 priority::high resolution::implemented review-group-5 review-group-8 reviewer::nickm rsos severity::normal status::closed tor-hs type::enhancement labels

This is an alternate design and implementation of the "Stream latency is reduced on a 4-hop circuit" feature of #prop252. (It reduces the path length, but does it in a different way to the proposal, by building a one-hop path to hidden/onion service introduction points and rendezvous points.)

These one-hop introduction point and rendezvous paths are compatible with the existing hidden service implementation, and it works on the existing tor network without any changes to older relays or clients.

Some sites wish to scale up public ".onion" sites within the next 6 months, using the existing Tor network and Tor clients. This patch enables their use case, until #prop252 is implemented and deployed widely enough.

Trac:
Status: new to needs_review

Trac:
Keywords: N/A deleted, 028-triaged added

Bulk-replace SponsorU keyword with SponsorU field.

Trac:
Keywords: SponsorU deleted, N/A added
Sponsor: N/A to SponsorU

Trac:
Points: N/A to large

Trac:
Keywords: 028-triaged deleted, 028-triaged tor-hs added

The one-hop circuits that were created by this code weren't marked as one-hop, which caused a info-level bug log message in the pathbias code.

I've pushed a fixup to the branch hs-route-len-v2. There's also a branch with the same changes based on Tor 0.2.6.10 at hs-route-len-02610.

I think this code needs a redesign (and a proposal) before it is merged, to:

• get community consensus on the tradeoffs between efficiency, features, and splitting the hidden service anonymity set
• collapse the two experimental options into a single option like OnionServerOneHop 1, which would do the equivalent of __OnionSrvIntroRouteLength 1 __OnionSrvRendRouteLength 0
• (I also dislike that one-hop paths need to have one of these settings as 1, and the other as 0. This should be handled internally and not exposed to operators.)

Trac:
Severity: N/A to Normal
Status: needs_review to needs_revision

I've created a new branch feature-17178-rsos that:

• adds a new boolean option RendezvousSingleOnionServiceNonAnonymousServer
• removes the previous options
• sets the one-hop flag in the functions which launch intro and rendezvous circuits
• simplifies the remaining code
• rebase onto the latest 0.2.8 (There's also feature-17178-rsos-02610 based on Tor 0.2.6.10.)

This can be tested with the chutney branch feature-17178-rsos at https://github.com/teor2345/chutney.git using src/test/test-network.sh --flavor rsos-min.

This code still needs the following before it can be merged:

• a proposal: to get community consensus on the tradeoffs between efficiency, features, and splitting the hidden service anonymity set, and
• unit tests.

Please see the draft proposal in my rsos branch in https://gitbhub.com/torspec.git I'll post it to tor-dev after another round of edits.

Trac:
Cc: N/A to asn

Status update:

The current implementation has one known issue:

• when RendezvousSingleOnionServiceNonAnonymousServer is changed at runtime, tor attempts to re-use introduction points and introduction point circuits after a HUP. It should close the circuits and discard the intro points.

The proposal has been updated and posted to tor-dev.

The proposal is available in the branch “feature-17178-rsos” at https://github.com/teor2345/torspec.git as torspec/proposals/ideas/xxx-rend-single-onion.txt

There is a basic implementation in the branch “feature-17178-rsos” at https://github.com/teor2345/tor.git

This can be tested with the chutney branch "feature-17178-rsos” at https://github.com/teor2345/chutney.git using the command: src/test/test-network.sh --flavor rsos-min

Trac:
Priority: Medium to High

Hello teor, what can I do here to help? What's the current status here? I can spend a few hours this week on this ticket.

Replying to asn:

Hello teor, what can I do here to help? What's the current status here? I can spend a few hours this week on this ticket.

The code works and has been tested using chutney.

It doesn't behave correctly when RendezvousSingleOnionServiceNonAnonymousServer Is changed at runtime (using torrc and a HUP, or over the control port). The current code attempts to re-use introduction points and introduction point circuits after a HUP. But if the value of RendezvousSingleOnionServiceNonAnonymousServer has changed, the circuits are the wrong length. Tor should close the circuits and discard the intro points (this needs to be coded), then post a fresh descriptor (this likely already happens anyway after a config change).

There aren't any specific unit tests, but any existing unit tests pass.

Replying to teor:

Replying to asn:

Hello teor, what can I do here to help? What's the current status here? I can spend a few hours this week on this ticket.

The code works and has been tested using chutney.

It doesn't behave correctly when RendezvousSingleOnionServiceNonAnonymousServer Is changed at runtime (using torrc and a HUP, or over the control port). The current code attempts to re-use introduction points and introduction point circuits after a HUP. But if the value of RendezvousSingleOnionServiceNonAnonymousServer has changed, the circuits are the wrong length. Tor should close the circuits and discard the intro points (this needs to be coded), then post a fresh descriptor (this likely already happens anyway after a config change).

This can be done yes, but it's some moderate engineering complexity. Are we sure we want RendezvousSingleOnionServiceNonAnonymousServer to be hotpluggable like that? We think HS operators would enjoy that, or can we just fail and warn the user if RSOS was enabled after a HUP?

And also there is the opposite direction. What happens if RSOS is disabled after a HUP? Then you need to kill all 1-hop circuits and make 3-hop ones? Do we want people to think it's so easy to switch between these two modes?

Replying to asn:

Replying to teor:

Replying to asn:

Hello teor, what can I do here to help? What's the current status here? I can spend a few hours this week on this ticket.

The code works and has been tested using chutney.

It doesn't behave correctly when RendezvousSingleOnionServiceNonAnonymousServer Is changed at runtime (using torrc and a HUP, or over the control port). The current code attempts to re-use introduction points and introduction point circuits after a HUP. But if the value of RendezvousSingleOnionServiceNonAnonymousServer has changed, the circuits are the wrong length. Tor should close the circuits and discard the intro points (this needs to be coded), then post a fresh descriptor (this likely already happens anyway after a config change).

This can be done yes, but it's some moderate engineering complexity. Are we sure we want RendezvousSingleOnionServiceNonAnonymousServer to be hotpluggable like that? We think HS operators would enjoy that, or can we just fail and warn the user if RSOS was enabled after a HUP? That's a really good point. The existing design deliberately doesn't support mixing HS and RSOS for security reasons. (See below.)

And also there is the opposite direction. What happens if RSOS is disabled after a HUP? Then you need to kill all 1-hop circuits and make 3-hop ones? If we were to close all connections, it would have to happen on both RSOS to HS, and HS to RSOS. But that's not secure. Do we want people to think it's so easy to switch between these two modes? You're right, we really can't allow hot-plugging securely and safely.

I think we need secure defaults here:

1. a Tor instance can only run all RSOS, or all HS at one time (RendezvousSingleOnionServiceNonAnonymousServer is global)
2. after an onion service is launched, a Tor instance can only run all RSOS, or all HS, until Tor is restarted (RendezvousSingleOnionServiceNonAnonymousServer is persistent on first RSOS/HS launch)

These rules protect operators from inadvertent disclosure by either simultaneously or sequentially running onion services with 1 and 3 hop paths on the same Tor instance. But they also support the ephemeral use-case, where the operator launches Tor, sets or unsets RendezvousSingleOnionServiceNonAnonymousServer, then launches an onion service.

I have implemented 1, but I haven't implemented 2 yet. To implement it, Tor needs to check: if RendezvousSingleOnionServiceNonAnonymousServer is changed, and there are any onion services active (excluding deleted/inactive services, if this is a feature of (ephemeral) services), then reject the change and warn the user. Tell them to restart if they really want to change it.

Can you help with that?

Yes. I aim to review the code and implement the missing logic this week. Let's see!

nickm says on IRC:

teor
Is it OK to make operators restart their tor instance to switch to/from (Rendezvous) Single Onion Services?

nickm
IMO absolutely yes; and in fact... the same datadirectory probably shouldn't let you do that without some kind of a "yes I know what I'm doing"
err,
the same hidden service directory