Re: [tor-bugs] #6411 [Tor]: Adding hidden services through control socket

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#6411: Adding hidden services through control socket
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:
  kevinevans             |     Status:  needs_revision
         Type:           |  Milestone:  Tor: unspecified
  enhancement            |    Version:  Tor: 0.2.3.19-rc
     Priority:  normal   |   Keywords:  hidden-service control maybe-
    Component:  Tor      |  proposal tor-hs
   Resolution:           |  Parent ID:  #8993
Actual Points:           |
       Points:           |
-------------------------+-------------------------------------------------

Comment (by meejah):

 It seems to me there are two parts here:

 1. create a hidden-service private key (without touching the filesystem).
 This could be a command-line option to tor (e.g. like --hash-password)
 that dumps to stdou or a controller command (e.g. "CREATE_HS_KEY" that
 returns the key-blob).

 2. add an HS private key to a running Tor.

 a) To fit in with the other HiddenService* options, it would probably make
 sense to have something like "HiddenServicePrivateKey" or similar that can
 take some kind of single-line giant-string representation of the private
 key. So this would be done via a SETCONF.

 OR b) a separate command that sets all the options at once or something
 for a hidden service (which is sort of what the above is?).

 For both the above, you still need some way to get the .onion address --
 either the controller has to write compatible code that derives from the
 private key, OR there's a controller command (e.g. some GETCONF thing?)
 that can tell you the .onion for a given hiddenservice.


 ----

 HOWEVER...

 I think this probably does warrant further discussion around a proposal on
 tor-dev -- although a "HiddenServicePrivateKey" option would fit in with
 the current scheme better, the current scheme is rather clunky for hidden-
 services, IMO. It is the only real "special case" GETCONF/SETCONF/torrc
 thing where order matters, *and* it is AFAIK the only user of "Dependant"
 or "Virtual" as a type.

 There is currently a decent chunk of code in txtorcon's torconfig.py
 classes to deal with the special-case of hidden-services vs. "normal"
 options, so it might make sense to configure hidden services differently
 entirely. One such idea:

 For filesystem-based HSes you put all the config for your service in the
 hidden-service-dir in some file ("config"? this would be the ports and
 such) and put a single option (HiddenService /foo/bar) in torrc

 OR you use a controller that knows how to speak the "set up a hidden
 service" commands, which would all be new. There's then also the matter of
 "what's the unique name of a hidden service?" which is currently "the
 hidden service dir" but of course that doesn't make sense if there isn't
 one at all.

 In other words, split the concept of an "ephemeral" (to tor) hidden-
 service (i.e. where a controller keeps all the config) versus a
 "permanent" one (i.e. where Tor knows where all the config is on the
 filesystem). Additionally, for people who want to do things like
 add/remove client authorizations "on the fly" it might be a lot easier to
 have controller commands like "HS_REMOTE_CLIENT hsname clientname".

 All that said I haven't thought about this too hard and a design proposal
 does sound like a good idea...

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6411#comment:11>
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