[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #17178 [Tor]: Single Onion Services: One-Hop Intro Point and Rendezvous
#17178: 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:
TorCoreTeam201511 | Resolution:
Parent ID: | Actual Points:
Sponsor: SponsorU | Points: large
-------------------------------------------------+-------------------------
Comment (by teor):
Replying to [comment:22 asn]:
> Replying to [comment:20 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.
> >
> OK, I coded this feature and pushed it in branch `feature-17178-rsos`.
Let me know if you like it.
Thanks, I'll have a look at it this week.
> I still feel a bit guilty for adding another 100 lines of rarely-used
code to `rendservice.c`, but...
>
> Also, I was not sure what to do about ephemeral hidden services who
don't have an HS directory.
Ephemeral hidden services don't need this feature:
* On HUP: RSOS / HS path lengths can't change, and
* On restart: ephemeral hidden service keys aren't persistent (so there is
no need to mark them as anonymous / non-anonymous).
If operators retrieve their own ephemeral keys, I think they can manage
anonymity as well.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/17178#comment:23>
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