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

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Feb 12 18:44:08 UTC 2015


#6411: Adding hidden services through control socket
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  yawning
  kevinevans             |     Status:  accepted
         Type:           |  Milestone:  Tor: 0.2.7.x-final
  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):

 Replying to [comment:24 naif]:
 > Yawning are you coming to Tor Dev Meeting in Valencia? Willing to bring
 Italian Red Wine!!!!!! :-)

 Yeah I will. :P

 So a minor update, I went and added the code to persist ephemeral HSes
 through configuration reload to my branch, so basic functionality is done
 (yay).  That said, I talked to nickm regarding the design a bit and he
 convinced me that allowing tor to (optionally) generate the private key on
 behalf of the user is a good idea.

 The command currently looks like: `ADD_EPH_HS keyType keyBlob [VIRTPORT
 TARGET]...` where `keyType` is `RSA1024`, `Ed25519` etc.

 This will most likely change to: `ADD_EPH_HS keyType:keyBlob [VIRTPORT
 TARGET]...` where:
  * On success, `250-OnionAddr=address.onion` is returned, in addition to
 the standard `250 OK` response.
  * A `keyType` of known algorithms (Eg: `RSA1024`, `Ed25519`) is treated
 the same as the old behavior, with an opaque blob in the appropriate
 format supplied by the user as `keyBlob`.
  * A `keyType` of `NEW` will have tor generate a new keypair of the
 algorithm specified in `keyBlob` (So, to get a new ephemeral HS with a RSA
 keypair, one would specify `NEW:RSA1024`).  As an ease of use thing, a
 `keyBlob` (in this case acting as the algorithm identifier) of `BEST` will
 generate the "best" algorithm supported by the tor instance.  On success
 in addition to the onion address and the OK response,
 `250-KeyPair=keyType:keyBlob` is returned, containing a `keyType`
 identifying the keypair algorithm, and `keyBlob` containing the serialized
 keypair suitable for future calls to `ADD_EPH_HS`.

 For example:

 Adding a new ephemeral HS, with a pre-existing RSA1024 key:
 {{{
 ADD_EPH_HS RSA1024:<opaque blob> 80 127.0.0.1:80
 250-OnionAddr=<blah blah blah>.onion
 250 OK
 }}}

 Adding a new ephemeral HS, with a newly generated Ed25519 key:
 {{{
 ADD_EPH_HS NEW:Ed25519 22 127.0.0.1:22
 250-OnionAddr=<foo bar baz>.onion
 250-KeyPair=Ed25519:<opaque blob>
 250 OK
 }}}

 Adding a new ephemeral HS, with a newly generated key, using the best
 supported algorithm:
 {{{
 ADD_EPH_HS NEW:BEST 443 127.0.0.1:443
 250-OnionAddr=<hoge hoge hoge>.onion
 250-KeyPair=RSA1024:<opaque blob>
 250 OK
 }}}

 This will allow:
  * People that know what they are doing to handle keypair generation.
  * People that don't know what they are doing, or don't trust themselves
 to do things correctly, to have Tor generate a HS keypair (and
 corresponding address) on their behalf, that they can continue to use in
 the future if they decide to save it.

 Unless anyone has massive objections as to why this is broken, this is
 what I will implement the next time I work on this.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6411#comment:25>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list