[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



#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 globalleaks-wants
   Resolution:           |  Parent ID:  #8993
Actual Points:           |
       Points:           |
-------------------------+-------------------------------------------------

Comment (by yawning):

 So, I said I'll look at this the other day in IRC.

 Replying to [comment:11 meejah]:
 > 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?).

 This is "b".

 > 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.

 I think for ephemeral hidden services, the key management and generation
 should be the application's problem.  That allows the app to persist it's
 HS key on it's own if it want's to.  Deriving the onion address from the
 public key is trivial as well.

 {{{
 ypres :: ~ % go get github.com/Yawning/orkey/or-key-tool
 ypres :: ~ % ~/.local/go/bin/or-key-tool
 File: - N/A (Generated) -
 Type: RSA1024 Private Key
 Fingerprint: 3B414C1DBF3638F47F946B8906D09D53FBB1F21C
 Identity (Base64): O0FMHb82OPR/lGuJBtCdU/ux8hw=
 Onion Addr: hnauyhn7gy4pi74u.onion

 -----BEGIN RSA PUBLIC KEY-----
  [Redacted Base64 encoded blob]
 -----END RSA PUBLIC KEY-----
 -----BEGIN RSA PRIVATE KEY-----
  [Redacted Base64 encoded blob]
 -----END RSA PRIVATE KEY-----

 ypres :: ~ %
 }}}

 [Snip]
 > 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.

 This seems the simplest.  I don't see what's wrong with using the onion
 addr to refer to each HS...  For something that's easy to do, and only
 requires a control spec patch:
 For the controller:
  * `ADD_EPH_HIDDENSERVICE KEY_TYPE PRIVATE_KEY [virtport targetAddr]...` -
 Initializes a hidden service, using the `KEY_TYPE` private key
 `PRIVATE_KEY` (so, something like "RSA1024 [Base64 encoded blob]"), with
 the HiddenServicePort list as specified.  (Key type is specified as a
 future-proofing measure).
  * `DEL_EPH_HIDDENSERVICE ADDR` - Removes the hidden service `ADDR`.

 Open questions:
  * `HiddenServiceAuthorizeClient` is kind of annoying, so I'm going to
 ignore it for now.
  * Is it unreasonable to expect people to be able to generate an RSA1024
 key, and compute/encode the digest?  I'm inclined to think that the added
 application flexibility here is worth forcing that onto the app code (and
 crap app code that doesn't generate keys properly get what they deserve).

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