[tor-dev] RFC: Ephemeral Hidden Services via the Control Port

[meejah]

Yawning Angel <yawning at schwanenlied.me> writes:

Cool! I added a quick try at using this in txtorcon, with an example;
see the following branch:

https://github.com/meejah/txtorcon/tree/yawning-feature-6411

(Most of that example code would actually end up in the
endpoint.listen() code and be hidden from most users of the library,
too. And would be the default instead of "launch a new tor").

> This does not support `HiddenServiceAuthorizeClient` yet in any way
> (neither basic nor stealth).  It may in the future, but coming up with
> a sane interface for it is way more pain than I am willing to
> self-inflict at the moment.

What about a similar API: add + remove a client-key. And similarly, you
could push a key yourself, or ask for a new one. The only difference
would be including the onion-address. Like:

   ADD_EPH_HS_ADD_CLIENT_AUTH kittenmeowae41f nickname0 stealth NEW:BEST
   ADD_EPH_HS_ADD_CLIENT_AUTH kittenmeowae41f nickname1 basic NEW:BEST

The return value would be the cookie (for basic) or both the cookie and
the key-blob for stealth. Or "NEW:BEST" could be "RSA1024:....." like
the other API?

For deleting you'd pass the onion ID and the nickname I guess. Like:

   ADD_EPH_HS_DEL_CLIENT_AUTH kittenmeowae41f nickname1

>  * meejah suggested that ephemeral hidden services should have their
>    lifetime tied to the originating control port connection.  I think
>    this is a good idea, but this would be the only control port command
>    that does this sort of thing.

__OwningControllerProcess is similar, I guess, but instead ties to the
whole lifetime of Tor (which sounds way easier to implement ;)

> Questions, comments, feedback appreciated,

I think it's looking quite nice!

-- 
meejah