[tor-dev] Changing Rendezvous Single Onion Service at Runtime

[teor]

Hi all,

Is there any reason an onion service would want to temporarily switch from 1-hop to 3-hop paths?
Is it ok if we force operators to restart the tor instance when onion service path lengths change?

The original proposal for rendezvous single onion services (RSOS) was silent on whether path lengths could change at runtime. (I honestly didn't think anyone would do that!)

The existing proposal doesn't allow operators to run hidden services (HS) and RSOS on the same Tor instance at the same time. I'd like to strengthen this security feature, and ensure operators can't run HS and RSOS on the same instance sequentially. This would also mean that operators can't switch an onion service's flavour from HS to RSOS or vice versa at runtime.

In detail, this means that after an onion service is launched, a Tor instance can only run all RSOS, or all HS, until Tor is restarted.
This design change protects operators from inadvertent network address disclosure from running onion services with 1 and 3 hop paths on the same Tor instance. But it also supports an ephemeral RSOS use-case, where the operator launches Tor, sets (or unsets) RendezvousSingleOnionServiceNonAnonymousServer, then launches an onion service.

To implement this change, 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.)

For what it's worth, the implementation is also much simpler if we force a restart when this parameter changes. If we start enforcing the recommended options, like disabling entry guards and pathbias, a restart will be even more important.

I've been talking with asn about this on Trac ticket #17178. Please feel free to comment by email or on the ticket. I'll modify the proposal after I'm sure this covers all use cases.

In summary:
Is there any rendezvous single onion service use case that wouldn't be possible with this new restriction?
I want to check we aren't breaking any neat onion service uses, if we force Tor to restart when changing path lengths.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20151107/4219a404/attachment-0001.html>