Hi,
The Warning: DO NOT USE MY BRANCH YET, IT HAS HAD MINIMAL TESTING AND REVIEW. IT IS NOT DONE. IT WILL BROADCAST YOUR SECRETS TO THE NSA'S ORBITAL SPACE STATION.
Trac Ticket: https://trac.torproject.org/projects/tor/ticket/6411 Branch: https://github.com/Yawning/tor/compare/feature6411
With that out of the way, I've been poking at implementing a way to add hidden services at runtime via the control port. I'm calling this "ephemeral hidden services" because the HS state is not written out to disk, and they disappear when the tor damon is shutdown.
Yes, this means that if you run "kittensomgmewmew.onion" and are scared of the NSA's persistent attempts to extract your hidden service key, via ultrasonic laser beamed from their satellites, you could run your tor instance entirely in a ram disk, and load the HS key manually each time from a USB token you wear around your neck.
What I've come up with looks like this:
ADD_EPH_HS - Adds a new ephemeral hidden service.
The syntax is:
"ADD_EPH_HS" keytype:keyblob SP 1*(port SP addrPort) CRLF keytype = "RSA1024", "NEW" keyblob = opaque ascii serialized key material, or an algorithm specifier, in the case of "keytype" == "NEW". port = the "VIRTPORT" addrPort = the "TARGET"
A hidden service is created using the key and list of port/targets, that will persist till configuration reload or the termination of the tor process.
The currently supported keytypes and keyblobs are:
"RSA1024" - The keyblob contains the Base64 encoding of the PKCS#1 layout DER representation of a 1024 bit RSA private key.
"NEW" - The tor instance should generate a key with the keytype specified in the keyblob parameter. A type of "BEST" will generate a key using the best supported algorithm.
Returns:
"250-ServiceID=serviceID" - The hidden service's onion address without the ".onion" suffix.
"250-PrivateKey=keytype:keyblob" - The newly generated hidden service's private key, if a keytype of "NEW" was specified.
"250 OK" - Everything went well.
Proper key management, is left as an exercise for the application invoking the controller command.
DEL_EPH_HS - Removes an existing ephemeral hidden service.
The syntax is:
"DEL_EPH_HS" serviceID CRLF serviceID = the hidden service identifier, without the trailing ".onion" suffix
The hidden service specified by the given service ID is removed, and the intro points are closed. Existing connections are left as is, and it is up to the application to close them if it wishes to do so.
Examples:
* Adding a new ephemeral hidden service, with a pre-generated RSA key: > ADD_EPH_HS RSA1024:[Base64 blob] 80 127.0.0.1:8080 < 250-ServiceID=blahblahblahblah < 250 OK
Hidden service is reachable at blahblahblahblah.onion:80
* Adding a new ephemeral hidden service, tor generates a new RSA key: > ADD_EPH_HS NEW:RSA1024 22 127.0.0.1:22 < 250-ServiceID=hogehogehogehoge < 250-PrivateKey=RSA1024:[Base64 blob] < 250 OK
Hidden service is reachable at hogehogehogehoge.onion:22. At a later date, the value passed back as "PrivateKey" can be used to re-create the hidden service.
* Add a new ephemeral hidden service, tor picks the algorithm: > ADD_EPH_HS NEW:BEST 1245 192.168.1.5:23 < 250-ServiceID=hemohemohemohemo < 250-PrivateKey=Ed25519:[Base64 blob] < 250 OK
Hidden service is reachable at hemohemohemohemo:23. (nb: Ed25519 key support is not actually implemented yet, and is used as an example of a better algorithm.)
* Remove the hidden service configured in the first example: > DEL_EPH_HS blahblahblahblah < 250 OK
Note: ADD_EPH_HS can take more than one VIRTPORT/TARGET pair at once, the examples only show one pair for brevity.
This does not support `HiddenServiceAuthorizeClient` yet in any way (neither basic nor stealth). It may in the future, but coming up with a sane interface for it is way more pain than I am willing to self-inflict at the moment.
Design question that I want feedback on, primarily from control port library maintainers, and authors of applications that use the control port:
* meejah suggested that ephemeral hidden services should have their lifetime tied to the originating control port connection. I think this is a good idea, but this would be the only control port command that does this sort of thing.
My motivations for strongly considering implementing this is that, I don't think that adding a command to enumerate hidden services is a good idea (SketchORChat has no business in seeing what hidden services JankORFileSharing is using), and that this will automate cleanup in the event of an application crashing, or not removing it's hidden services before terminating.
* Does this interface expose enough functionality, in a way that is intuitive and easy to use? (The initial version I was planning on proposing made key generation entirely the application's problem, but nickm convinced me otherwise).
Questions, comments, feedback appreciated,