Opened 10 years ago

Closed 5 years ago

Last modified 5 years ago

#1949 closed enhancement (fixed)

set up a hidden service without using a filesystem directory?

Reported by: arma Owned by:
Priority: Low Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Keywords: tor-hs
Cc: special@…, meejah@… Actual Points:
Parent ID: #8993 Points:
Reviewer: Sponsor: SponsorR


In the original hidden services model, the expert user would set up a directory on the disk somewhere, edit her torrc to configure a hidden service to write its hostname and key in that directory, start tor, and go look in that directory to find out the new name for the hidden service.

That model sucks if we want hidden services to be easy and safe for ordinary users.

In particular, there are two reasons why it's bad. First, the Tor client runs as whatever user it runs as, and the user needs to pick a directory that Tor can write to and read from. Where that might be probably varies from Linux distro to distro. Second, the private key of the service gets written unencrypted to disk. We could imagine expert users who know how to handle that, but we can also imagine that most users won't.

So it would be good to make an easier way to do it. One way would be to allow controllers to set up hidden services. The controller could even remember the key (and store it in a safe way), and import it to Tor when it connects to the control port. (We don't want controllers generating hidden service keys though -- that's Tor's job.)

I could imagine an API in the control protocol that allows this -- with operations like "make me a new hidden service and tell me the key" or "here's the key, please set up a hidden service". I wonder if there's a more general way to extend the controller protocol though?

Child Tickets

Change History (16)

comment:1 Changed 10 years ago by n8fr8

We have been prototyping something like this with Orbot, designed around the Android Intent architecture. Intents provided an app-to-app interface, and the idea is for any Android app to be able to request a hidden service on a specific port, and in return receive the onion address info (either a unique address or shared, based on user pref).

Orbot is sublaunched when the app makes this request, and the presents its own UI informing the user that such and such app is requesting to use a hidden service, and if that is okay, etc.

This is more anecdotal than specific in terms of affecting the controller design you are proposing, but I thought it might be helpful in terms of thinking about how users might be exposed to the creation of hidden services.

comment:2 Changed 10 years ago by special

Cc: special@… added

comment:3 Changed 10 years ago by nickm

Milestone: Tor: 0.2.3.x-final
Priority: normalminor

Marking for 0.2.3.x.

One interface that might work for this is to allow the user to specify a symbolic name rather than a directory for a service. If they do this, then the keys and other info for that service get stored in a $DATADIR/hs/$HSNAME/ directory, and the controller can get the .onion address of the name via something like GETINFO hs/$HSNAME/address .

This idea doesn't do anything about the fact that it's still annoying to adjust the hidden service settings via SETCONF (since you need to replay all the current hidden service settings you're not changing). I think that's just an annoyance though: it would only become a real problem if you've got so many hidden hidden services that Tor can't handle them anyway.

comment:4 Changed 10 years ago by special

That solution would not work for my use case. I want to avoid ever having the hidden service keys on the filesystem - so that the controller can manage safe, secure storage. That means it would need some method of exchanging the service key itself over the control protocol (possibly still via settings).

As for the replaying to SETCONF, that is a much lesser issue. It could theoretically be a race condition that would result in some service being left out, but I don't think that's a primary concern.

comment:5 Changed 10 years ago by nickm

ok, so two options there: for that we'd need add an additional hidden service argument to indicate that hidden services shouldn't be persistent between Tor invocations, and every time that Tor restarts, it should generate a new key for the service. Not a crazy idea.

comment:6 Changed 10 years ago by nickm

03:32 < special> short version.. it's hidden service based IM that creates and 
                 publishes services via the control port. Tor insists on 
                 writing the secret key unencrypted to disk, which is both 
                 severely inconvenient and assumes that the user's disk is a 
                 safe place
03:32 < nickm> where do you  want to put them instead?
03:33 < special> I would like to store the keys as part of the rest of the 
                 application's settings, where I can allow the user to encrypt 
                 them and make sure they're not lost
03:35 < special> in other words, as the controller, I want to be able to 
                 configure a service by telling Tor the secret key, and create 
                 a service by asking Tor to give me the secret key.
03:38 < special> sound sensible? I'm pretty distracted, so that's not the most 
                 clear explanation I could come up with.
03:39 < nickm> hm.  sounds plausible to me.  we don't have an excellent way to 
               give something as big as a private key as a configuration option 
               right now, but there's no reason that couldn't change.

So we would also need A) a way to flag a hidden service as "do not save this to disk at all", B) a way to use GETINFO to get a hidden service's private key, and C) a way to tell Tor a hidden service's key when you configure it.

A is not so hard. B is fairly easy, once we pick a format. C is potentially tricky to find the right interface for, but ultimately shouldn't be too bad.

comment:7 Changed 9 years ago by arma

Component: Tor ClientTor hidden services

comment:8 Changed 9 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: unspecified

comment:9 Changed 8 years ago by nickm

Keywords: tor-hs added

comment:10 Changed 8 years ago by nickm

Component: Tor Hidden ServicesTor

comment:11 Changed 7 years ago by arma

Parent ID: #8993

comment:12 Changed 6 years ago by special

nickm and I repeated the conversation above, having gained 4 more years of wisdom. We came to largely the same conclusions.

We thought that a private key could be an option on a single, very long line:

[17:13] <special> it would allow us to have options like __HiddenServicePrivateKey and __HiddenServiceClientKeys
[17:13] <special> assuming the control-spec could also handle these multiline options, which it certainly cannot
[17:13] <nickm> maybe have huge lines?
[17:18] <nickm> and if they're just used by a controller, then you can totally make them into huge lines.

And that using HiddenServiceDir to declare an identifier, with a __HiddenServicePrivateKey suboption, would make most sense:

[17:15] <special> the intention would be for those options to be defined by a controller and not saved to the torrc
[17:24] <nickm> Hm.  The way that the logic works, it would be easier to have a special value for HiddenServiceDir that means "No directory", and make __HiddenServicePrivateKey a suboption.
[17:25] <nickm> The HiddenServiceDir option could maybe have some way to give an identifier for the controller's use, so that the GETINFO commands could differentiate between multiple hidden services
[17:25] <special> true. that would also make it neater to create a new service, because you could do it by defining a service with no directory and not giving it a private key.
[17:29] <special> SETCONF HiddenServiceDir="memory myfancyservice" HiddenServicePort="80" \r\n GETINFO hs/myfancyservice/hostname hs/myfancyservice/private-key \r\n

And that the other problems with hidden services for controllers should be handled separately:

[17:35] <special> it's not as nice from the implementation-by-controllers perspective: it doesn't solve the "setconf of a hidden service overwrites all other hidden services" problem, for example.
[17:36] <nickm> That's a general problem with how multiline configuration options interact with controllers.  Maybe we should try to solve that independently

[17:37] <special> it's also not-good if you're not okay with all controllers having access to the private key
[17:39] <nickm> Multiple non-interacting controllers, or controllers with limited privileges, is also unsolved.
[17:41] <special> yeah. I think I agree that those problems should be solved separately. I was wondering if some special control-spec commands for defining services would make sense, but that doesn't seem to pan out.

We need to define how these options are treated when read from torrc (as opposed to SETCONF). I think these options shouldn't be allowed from any source other than SETCONF, and should never be written to disk.

The next step is to figure out what single line format we could put private_key and client_keys in.

comment:13 Changed 6 years ago by meejah

Cc: meejah@… added

comment:14 Changed 6 years ago by naif

This ticket, together with #13865 using TxTorCon applications such as GlobaLeaks would be able to use Tor without having to deal with FileSystem interaction!

comment:15 Changed 5 years ago by dgoulet

Keywords: SponsorR added
Resolution: fixed
Status: newclosed

With #6411 now merged, I think this one is finally done after 5 years! :)

comment:16 Changed 5 years ago by dgoulet

Keywords: SponsorR removed
Sponsor: SponsorR
Note: See TracTickets for help on using tickets.