Adding hidden services through control socket
Okay, first off, I should say: 1) I'm relatively new to Tor and 2) I don't know C that well.
A while back, I thought that it was a bad idea to have the hidden service hostname/privkey being written to the filesystem, unless it's either a tmpfs or an encrypted volume. For programs like Torchat (or alike), it would seem better to be able to hide the private key/hostname in an encrypted file (for example) versus in a filesystem.
In the patch, I have added an ADDSERVICE command (after it's authenticated), and its arguments are: [hostname] [private key] [vport0] [rport0] [vport1] [rport1] ... [vport*] [rport*]
I wasn't sure about which status codes to use, so I just used whatever. The code is rather inefficient, frankly because I'm awful at C and I'm probably causing a memory leak by not freeing some memory.
Trac:
Username: kevinevans
Activity
changed milestone to %Tor: 0.2.7.x-final
added 027-triaged-1-out component::core tor/tor control globalleaks-wants hidden-service maybe-proposal milestone::Tor: 0.2.7.x-final nickm-review owner::yawning parent::8993 priority::medium reporter::kevinevans resolution::implemented status::closed tor-hs type::enhancement version::tor 0.2.3.19-rc labels
Trac:
Username: kevinevans-
Trac:
Username: kevinevans -
Trac:
Username: kevinevans This ticket is very similar to https://trac.torproject.org/projects/tor/ticket/5976 . It may be worth to evaluate if both two complete one each/other during the review-phase of this patch set.
This could use a design proposal -- as it stands, I'm not really sure what the command is supposed to do, since there's no documentation for it. At the very least, it needs a patch for control-spec to explain what it does.
Some other issues a proposal should address:
Why does the controller need to generate their own private key?
Why does the controller need to figure out the hostname? Why is it even there -- the code never looks at it except to check its length.
The patch itself has some issues that would need to be fixed, including:
- It parses a controller line in rendservice.c. By convention, all the controller parsing is done in control.c; rendservice.c should get at most a new "add a service" function.
- There's a heap overflow if the private key argument is too long.
- It checks to make sure that there are enough arguments after it's already looked at one of them.
- It fails badly if there are an odd number of ports, or if parse_port_config fails.
- The variable "p" doesn't have any purpose.
Trac:
Status: needs_review to needs_revision
Trac:
Parent: N/A to #8993 (moved)Is it possible to foresee integration of something like that in 0.2.6 ?
It would be extremely useful for proper, clean integration of Tor within GlobaLeaks, being fully managed by the application code. /cc @meejah
Trac:
Cc: N/A to lists@infosecurity.ch
It seems to me there are two parts here:
-
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).
-
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?).
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.
HOWEVER...
I think this probably does warrant further discussion around a proposal on tor-dev -- although a "HiddenServicePrivateKey" option would fit in with the current scheme better, the current scheme is rather clunky for hidden-services, IMO. It is the only real "special case" GETCONF/SETCONF/torrc thing where order matters, and it is AFAIK the only user of "Dependant" or "Virtual" as a type.
There is currently a decent chunk of code in txtorcon's torconfig.py classes to deal with the special-case of hidden-services vs. "normal" options, so it might make sense to configure hidden services differently entirely. One such idea:
For filesystem-based HSes you put all the config for your service in the hidden-service-dir in some file ("config"? this would be the ports and such) and put a single option (HiddenService /foo/bar) in torrc
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.
In other words, split the concept of an "ephemeral" (to tor) hidden-service (i.e. where a controller keeps all the config) versus a "permanent" one (i.e. where Tor knows where all the config is on the filesystem). Additionally, for people who want to do things like add/remove client authorizations "on the fly" it might be a lot easier to have controller commands like "HS_REMOTE_CLIENT hsname clientname".
All that said I haven't thought about this too hard and a design proposal does sound like a good idea...
-
-
Replying to naif:
Is it possible to foresee integration of something like that in 0.2.6 ?
Probably not; 0.2.6 is already entering feature freeze and this patch set is not up to scratch.
Trac:
Keywords: hidden-service control maybe-proposal tor-hs deleted, hidden-service control maybe-proposal tor-hs goballeaks-wants added