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

[Tor Bug Tracker & Wiki]

#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:19 asn]:
 > Hello, please see branch `feature-17178-rsos` in my repo for the code
 that blocks
 > RSOS hotplugging. That was easy to do.
 >
 > Now if we want to do more fancy stuff like "don't allow transitioning
 between
 > RSOS and normal HS even after restart", then we need to do more stuff
 (like put
 > a notice in the hidden service dir that RSOS was enabled). I'm wondering
 if we
 > should get in this trouble.

 Ideally, we should mark every key that is used for a HS or RSOS on first
 use, and refuse to use it for the other flavour/purpose unless an option
 like PermitNonAnonymousMultiUseOnionServiceKeys is set.

 But I don't like the idea of modifying keys. So instead, we could write a
 file to the directory that says whether the keys were last used for an
 anonymous or non-anonymous service.

 I think the security benefits are worth the extra complexity, and I can't
 see how to make it work without an extra file in the onion service
 directory.

 (As a comparison, Tor2Web will only run with a different binary (with a
 compilation flag) and specific torrc option.)

 > BTW, I noticed there is no code that blocks cannibalization of
 rendezvous
 > circuits. I remember that this was a problem in the past, since you
 ended up
 > cannibalizing 3-hop circuits all the time. Is this something we don't
 care
 > anymore, or maybe it was never a problem?

 I improved the code so the one-hop flag is set on intro and rendezvous
 circuits. (The previous code modified the path length calculation.)
 Circuits with the one-hop flag never cannibalize existing circuits, and
 aren't themselves cannibalized.

 It makes for much simpler code, and the flag is set where the circuit is
 initiated, so it's more readable, too. (And setting the one-hop flag makes
 the rest of the code treat the circuits like it does other one-hop
 circuits, which is also a win.)

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