Re: [tor-bugs] #17178 [Tor]: Single Onion Services: One-Hop Intro Point and Rendezvous

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#17178: Single Onion Services: One-Hop Intro Point and Rendezvous
--------------------------------+------------------------------------
 Reporter:  teor                |          Owner:
     Type:  enhancement         |         Status:  needs_revision
 Priority:  High                |      Milestone:  Tor: 0.2.8.x-final
Component:  Tor                 |        Version:
 Severity:  Normal              |     Resolution:
 Keywords:  028-triaged tor-hs  |  Actual Points:
Parent ID:                      |         Points:  large
  Sponsor:  SponsorU            |
--------------------------------+------------------------------------

Comment (by teor):

 Replying to [comment:15 asn]:
 > Replying to [comment:14 teor]:
 > > Replying to [comment:13 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?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17178#comment:16>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs