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

[Tor Bug Tracker & Wiki]

#6411: Adding hidden services through control socket
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  yawning
  kevinevans             |     Status:  needs_review
         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:50 special]:
 > There's no way to change the target ports for a service other than
 calling DEL_ONION and ADD_ONION again, which has side effects (like
 getting all new IPs, disruptions). This becomes even more relevant if we
 add client authentication data later, for example.
 >
 > Use case: I was thinking about modifying onionwrap[1] to monitor ports
 bound by its child process and forward all of them. It would sometimes
 need to add new ports.
 >
 > The obvious option is to allow ADD_ONION to update the properties
 (ports, detach?) of an existing service, but this is a problem for fully
 ephemeral services where the controller didn't even get a PK.
 >
 > But, it seems excessive to add CHANGE_ONION just for this case.
 >
 > It's also acceptable to ignore this problem, and if someone later thinks
 that we need a better solution than DEL/ADD, they can discuss and
 implement it.
 >
 > Thoughts?

 I'm leaning towards deferring this for future revisions, but I would lean
 towards `CHANGE_ONION` (or similar, name irrelevant) because eventually
 this functionality should have support for the various authentication
 mechanisms, which could/should be dynamically modifiable as well.

 There isn't a problem of not getting a private key back to handle
 `ADD_ONION` supporting modification if that's desired (Eg: the
 `keyType:keyBlob` could be something like `SERVICEID:<ServiceID>`, which
 would explicitly indicate that modification is wanted).

 Modifying `ADD_ONION` may be easier in the short run, but I'd like to see
 how HS authentication fits into the picture before commiting to that path.

 Ps: The `onionwrap` code is a tech demo held together by ducttape, chewing
 gum and bits of string.

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