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

[Tor Bug Tracker & Wiki]

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

Comment (by teor):

 Replying to [comment:33 asn]:
 > Replying to [comment:31 teor]:
 > > My branch feature-17178-rsos is ready for review on
 https://github.com/teor2345/tor.git
 >
 > Please see my branch `feature-17178-rsos` for a unittest on the
 poisoning functionality.

 Cherry-picked to my branch `feature-17178-rsos`.

 > Also, I feel a bit uneasy about code like this:
 > {{{
 > +      if (!options->RendezvousSingleOnionServiceNonAnonymousServer) {
 > +        service->next_upload_time += crypto_rand_int(2*rendpostperiod);
 > +      }
 > }}}
 > It's a bit like we are treating location-hidden services as a special
 case, whereas we should probably have it be the default case. I don't mind
 the specific snippet above, but maybe we could functionify the RSOS option
 check to also make it a bit nicer (since it's huge and unreadable). Maybe
 we could put it in a function `service_has_no_location_hiding()` (or some
 nicer name please).

 For this particular case, refactored into rend_reveal_startup_time(),
 which applies to RSOS and will apply to SOS.

 > Similarly I don't like:
 > {{{
 >  #ifndef NON_ANONYMOUS_MODE_ENABLED
 > -  tor_assert(!(circuit->build_state->onehop_tunnel));
 > +  if (!get_options()->RendezvousSingleOnionServiceNonAnonymousServer) {
 > +    tor_assert(!(circuit->build_state->onehop_tunnel));
 > +  }
 >  #endif
 > }}}
 > these asserts used to make the code look terrible, and now they are
 worse. The number of negative clauses in those asserts makes it even more
 confusing. Do you think we could functionify those asserts similar to
 `assert_circuit_ok()`?

 Refactored into assert_circ_onehop_ok(), which uses the new function
 rend_allow_direct_connection(). rend_allow_direct_connection() is true
 when in Tor2web or RSOS modes. (But won't be true for SOS, as they accept
 incoming client extend requests rather than making requests.)

 > Also, shouldn't we assert that if we are in RSOS mode, '''it is''' a one
 hop tunnel?

 No, the security property we're asserting is that standard hidden services
 (and clients) *must* make 3-hop paths for everything except directory
 connections. This keeps their location hidden.

 When we don't care about location hiding (RSOS, Tor2web), then there may
 be other reasons to make 3-hop paths. For example, RSOS make 3-hop paths
 to HSDirs to avoid denial of service attacks.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17178#comment:34>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online