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
On Nov 6, 2015, at 4:16 PM, teor teor2345@gmail.com wrote: Hi all,
Hiya!
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?
Well - as a user of RSOS, given the current state of the tor codebase, I feel it’s entirely reasonable that having a daemon need to cold-start in order to use oddball and privacy-impacting functionality be enabled.
By comparison: Tor2web requires being compiled-in before you can futz with connection configurations, and bans attempts to simultaneously set up connections in T2W and “normal” mode, so RSOS by comparison appears user-friendly. :-)
- alec
On Fri, Nov 6, 2015 at 11:16 AM, teor teor2345@gmail.com wrote:
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?
Just said on IRC, but saying here too for the record:
IMO it's fine to require a restart for now. And in fact, there should be some kind of affirmative opt-in to switch a hidden service directory from one to the other.
Treating these two kinds of services as interchangeable at service-side is IMO a recipe for bad times.
-
Alec Muffett -
Nick Mathewson -
teor