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,
--
Yawning Angel
Attachment:
pgp7rydYC6r7E.pgp
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev