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

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue Feb 10 15:05:47 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):

 Ok, I just went and updated the branch to add `DEL_EPH_HS`, which does
 exactly what is expected on the tin.  Before I send this off to review,
 the following questions need discussion/answers:

  * Should `ADD_EPH_HS` return more than "OK"?  If so, what?
  * What should happen to ephemeral hidden services on config reload?  The
 current behavior is to kill off the intro points and remove the HS (this
 leaves existing clients unaffected, but will disallow new clients), which
 mimics what happens when a HS is removed during a config reload.
  * Should `DEL_EPH_HS` be case sensitive for the service id?  It currently
 is not.
  * Should `DEL_EPH_HS` close only the intro points, or also existing
 client connections?  Current behavior is the former, changing it to the
 latter is easy-ish.
  * Does `DEL_EPH_HS` need to scrub the service ID that it removed?

 Known issues (Beyond the open design questions, most minor):
  * There's a bit of code duplication between `rend_config_services()` and
 `rend_service_del_ephemeral()`, on the off chance that behavior between
 the two will diverge.  I should carve out a new function if the behavior
 is going to be the same (as it is now).
  * `rend_service_get_by_service_id()` doesn't use constant time compares,
 because it is case insensitive. (Probably ok?).
  * Not much key validation is done in `crypto_pk_base64_decode()`, the
 next time I touch it I should add a `crypto_pk_check_key()` at a
 minimum...
  * I need to validate that the RSA key is actually 1024 bits...

 Going to tag this as needs_information, and set it aside till proper
 behavior is established, then finish off the known issues.  It's basically
 done at this point, but people still shouldn't use my branch.

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


More information about the tor-bugs mailing list