[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #17178 [Tor]: Rendezvous Single Onion Services: One-Hop Intro Point and Rendezvous
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs