[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
Hi Yawning, nice addition! As requested moving from irc to here.
One gotcha to think about is that ADD_EPH_HS is using a variable
number of positional arguments. This will limit your ability to expand
this command in the future with new arguments. Also, I'd suggest
renaming addrPort to addrTarget (to avoid making this sound restricted
to a simple port).
Other than that spec looks great. Looking forward to it! -Damian
On Fri, Feb 13, 2015 at 4:45 PM, Yawning Angel <yawning@xxxxxxxxxxxxxxx> wrote:
> 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
>
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev