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:
 Priority:  High                                 |  needs_revision
Component:  Tor                                  |      Milestone:  Tor:
 Severity:  Normal                               |  0.2.8.x-final
 Keywords:  028-triaged, tor-hs,                 |        Version:
  TorCoreTeam201511                              |     Resolution:
Parent ID:                                       |  Actual Points:
  Sponsor:  SponsorU                             |         Points:  large
-------------------------------------------------+-------------------------
Changes (by teor):

 * status:  needs_review => needs_revision


Comment:

 Reviewing asn's HS/RSOS poisoning changes:
 * code looks good, but I wonder if we should make it generic, so we can
 use it with single onion services as well, by using more generic terms,
 like SOS and "non-anonymous onion service":
 {{{
 #define SOS_POISON_FNAME "non_anonymous_onion_service"
 }}}
 * There's a warning for ephemeral RSOS, but I think it's actually an
 acceptable use case. The keys aren't persistent, so there's no issue with
 reuse in anonymous/non-anonymous modes. Maybe make it a log_info and
 remove the "can't be"?
 {{{
 log_warn(LD_GENERAL, "Ephemeral HS can't be started as RSOS.");
 }}}

 Running the changes:
 * chutney verify works using chutney rsos-min network in the chutney
 feature-17178-rsos branch
 * changing from RSOS to HS or HS to RSOS and then doing a HUP fails.
 * changing from RSOS to HS and then relaunching tor fails.

 Changing from HS to RSOS in the torrc and relaunching doesn't fail. I
 think this is OK, because we need an upgrade path for hidden service
 operators to deliberately upgrade to a rendezvous single onion service if
 they want to. And I don't like the idea of making operators touch a file
 in the filesystem to use RSOS.

 We already have an extensive warning the first time we start up with RSOS
 and poison the directory. Is this sufficient for the HS -> RSOS case?

 {{{
 [warn] RendezvousSingleOnionServiceNonAnonymousServer (RSOS) is set. Every
 hidden/onion service on this instance is NON-ANONYMOUS. Clients remain
 location-anonymous, but may be statistically distinguishable. If RSOS is
 disabled, Tor will refuse to  launch RSOS hidden services to protect
 against misconfiguration errors. This setting is for experimental use
 only.
 }}}

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17178#comment:24>
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