Re: [tor-bugs] #1949 [Tor]: set up a hidden service without using a filesystem directory?

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

#1949: set up a hidden service without using a filesystem directory?
-----------------------------+------------------------------
     Reporter:  arma         |      Owner:
         Type:  enhancement  |     Status:  new
     Priority:  minor        |  Milestone:  Tor: unspecified
    Component:  Tor          |    Version:
   Resolution:               |   Keywords:  tor-hs
Actual Points:               |  Parent ID:  #8993
       Points:               |
-----------------------------+------------------------------

Comment (by special):

 nickm and I repeated the conversation above, having gained 4 more years of
 wisdom. We came to largely the same conclusions.

 We thought that a private key could be an option on a single, very long
 line:
 {{{
 [17:13] <special> it would allow us to have options like
 __HiddenServicePrivateKey and __HiddenServiceClientKeys
 [17:13] <special> assuming the control-spec could also handle these
 multiline options, which it certainly cannot
 [17:13] <nickm> maybe have huge lines?
 [17:18] <nickm> and if they're just used by a controller, then you can
 totally make them into huge lines.
 }}}

 And that using `HiddenServiceDir` to declare an identifier, with a
 `__HiddenServicePrivateKey` suboption, would make most sense:
 {{{
 [17:15] <special> the intention would be for those options to be defined
 by a controller and not saved to the torrc
 [17:24] <nickm> Hm.  The way that the logic works, it would be easier to
 have a special value for HiddenServiceDir that means "No directory", and
 make __HiddenServicePrivateKey a suboption.
 [17:25] <nickm> The HiddenServiceDir option could maybe have some way to
 give an identifier for the controller's use, so that the GETINFO commands
 could differentiate between multiple hidden services
 [17:25] <special> true. that would also make it neater to create a new
 service, because you could do it by defining a service with no directory
 and not giving it a private key.
 [17:29] <special> SETCONF HiddenServiceDir="memory myfancyservice"
 HiddenServicePort="80 127.0.0.1:80" \r\n GETINFO
 hs/myfancyservice/hostname hs/myfancyservice/private-key \r\n
 }}}

 And that the other problems with hidden services for controllers should be
 handled separately:
 {{{
 [17:35] <special> it's not as nice from the implementation-by-controllers
 perspective: it doesn't solve the "setconf of a hidden service overwrites
 all other hidden services" problem, for example.
 [17:36] <nickm> That's a general problem with how multiline configuration
 options interact with controllers.  Maybe we should try to solve that
 independently

 [17:37] <special> it's also not-good if you're not okay with all
 controllers having access to the private key
 [17:39] <nickm> Multiple non-interacting controllers, or controllers with
 limited privileges, is also unsolved.
 [17:41] <special> yeah. I think I agree that those problems should be
 solved separately. I was wondering if some special control-spec commands
 for defining services would make sense, but that doesn't seem to pan out.
 }}}

 We need to define how these options are treated when read from torrc (as
 opposed to SETCONF). I think these options shouldn't be allowed from any
 source other than SETCONF, and should never be written to disk.

 The next step is to figure out what single line format we could put
 private_key and client_keys in.

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