Hi everyone, TL;DR: Please let me know how to fetch the hostname of my hidden service from Tor's control port. Say I have configured torrc to set up a hidden/onion service. By default, it's set up in /var/lib/tor/hidden_service, a directory which isn't world-readable. My software can authenticate into Tor's control port, but it needs to know the hostname/address of the service. It can't read the hidden_service/hostname file directly, and so far I haven't figured out how to query Tor for that information. As a last resort, I suppose I could copy /var/lib/tor/hidden_service/hostname to a directory that the software can read, but I'd like to avoid that if possible. I have hunted through https://gitweb.torproject.org/torspec.git/tree/control-spec.txt without too much success. The closest I have come is "GETCONF HiddenServiceOptions" but I suspect that the option is under GETINFO instead. However, the documentation mostly describes how to query information about other onion services. I need to know about my service though, if that's possible. Please advise. -- Jesse V I look forward to seeing everyone again in July at Minneapolis. :)
Jesse V <kernelcorn@riseup.net> writes:
TL;DR: Please let me know how to fetch the hostname of my hidden service from Tor's control port.
There are two types of onion services: "on disk" ones configured via torrc/SETCONF and the HiddenServiceDir and related options **or** "ephemeral" onions, created via the recently added ADD_ONION command. In the latter case, you can list them with GETINFOs on "onions/current" or "onions/detached" depending on the options when you created them. For the "HiddenServiceDir" onions, the only way to get the onion address that I know of is by reading the "hostname" file. Can you describe what you're trying to do? -- meejah
On 09/04/2016 09:31 PM, meejah wrote:
There are two types of onion services: "on disk" ones configured via torrc/SETCONF and the HiddenServiceDir and related options **or** "ephemeral" onions, created via the recently added ADD_ONION command.
In the latter case, you can list them with GETINFOs on "onions/current" or "onions/detached" depending on the options when you created them.
For the "HiddenServiceDir" onions, the only way to get the onion address that I know of is by reading the "hostname" file.
Can you describe what you're trying to do?
I'm interested in the ones on disk. I wish that "onions/current" would give me the list of HSs that were set up via torrc, but this doesn't appear to be the case. I'm basically looking for the raw command. This is part of my overhaul of the Onion Name System (OnioNS) project, which has actually been silently active. I wasn't able to finish some components until the design was stable. Now that the paper is finalized and has been accepted, I have been finishing the codebase. The server software needs to know the HS address so that it can distribute it to other nodes in the OnioNS network. My to-do list is quickly diminishing but I did run into this snag and I wasn't able to fix it. -- Jesse V
Jesse V <kernelcorn@riseup.net> writes:
I'm interested in the ones on disk. I wish that "onions/current" would give me the list of HSs that were set up via torrc, but this doesn't appear to be the case. I'm basically looking for the raw command.
Could you use ADD_ONION instead? Why are you using the on-disk API if you don't want to give your thing permission to read those directories? I also don't see why you'd give something permission to use the control-port, but *not* permission to read hostname/private_key files...? (p.s. I can't reach http://onions55e7yam27n.onion/) -- meejah
On 09/05/2016 12:43 AM, meejah wrote:
Could you use ADD_ONION instead? Why are you using the on-disk API if you don't want to give your thing permission to read those directories?
I'll consider it, but I want the onion service to be relatively permanent. It would best if the hostname didn't change every time tor restarted.
I also don't see why you'd give something permission to use the control-port, but *not* permission to read hostname/private_key files...?
I'd just rather not risk unnecessary exposure of private keys. The software doesn't need the key, so I'm risking compromise just to do private -> public -> hostname, I'd rather query the hostname directly. I'm using cookie authentication and both tor and onions-server have a copy of the cookie file. This way I can set up IPC between them in a more secure manner and they can each run as a separate user.
(p.s. I can't reach http://onions55e7yam27n.onion/)
Nothing is online at the moment. I'll make a separate post once everything is ready. -- Jesse V
On Mon, 5 Sep 2016 09:01:01 -0400 Jesse V <kernelcorn@riseup.net> wrote:
On 09/05/2016 12:43 AM, meejah wrote:
Could you use ADD_ONION instead? Why are you using the on-disk API if you don't want to give your thing permission to read those directories?
I'll consider it, but I want the onion service to be relatively permanent. It would best if the hostname didn't change every time tor restarted.
You realize that ADD_ONION supports using an existing private key right? Like this: ADD_ONION RSA1024:[Blob Redacted] Port=80,192.168.1.1:8080 Regards, -- Yawning Angel
meejah <meejah@meejah.ca> writes:
[ text/plain ] Jesse V <kernelcorn@riseup.net> writes:
TL;DR: Please let me know how to fetch the hostname of my hidden service from Tor's control port.
There are two types of onion services: "on disk" ones configured via torrc/SETCONF and the HiddenServiceDir and related options **or** "ephemeral" onions, created via the recently added ADD_ONION command.
In the latter case, you can list them with GETINFOs on "onions/current" or "onions/detached" depending on the options when you created them.
I guess a side question here is why those GETINFO commands only return the ephemeral onion services and not all of them. We should probably provide a common interface for getting the hostname of onion services, regardless of whether they are ephemeral or permanent. Also, by making this a control port command, Tor libraries can fetch it without doing weird filesystem IO. Anyone who wants to open a ticket here, or has a counter argument? :)
For the "HiddenServiceDir" onions, the only way to get the onion address that I know of is by reading the "hostname" file.
Can you describe what you're trying to do?
-- meejah _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On Thu, 08 Sep 2016 13:55:05 +0300 George Kadianakis <desnacked@riseup.net> wrote:
I guess a side question here is why those GETINFO commands only return the ephemeral onion services and not all of them.
Because when I added it, it was part of the ADD_ONION code, and I was too lazy to make it cover the other stuff.
Anyone who wants to open a ticket here, or has a counter argument? :)
Beyond the usual concerns of "the control port allows access to too much, and has no concept of isolation or ACLs, and this would be a step towards the worse", not really. Regards, -- Yawning Angel
George Kadianakis <desnacked@riseup.net> writes:
I guess a side question here is why those GETINFO commands only return the ephemeral onion services and not all of them.
We should probably provide a common interface for getting the hostname of onion services, regardless of whether they are ephemeral or permanent. Also, by making this a control port command, Tor libraries can fetch it without doing weird filesystem IO.
Personally, I think usage should preferentially go to "the new way" (ADD_ONION) since there's no really good way to hide the fact that the torrc "HiddenServiceDir" API *is* "weird filesystem IO". For example, if you want the private key, then you need to do "weird filesystem IO". Practically speaking: txtorcon would still need to do filesystem stuff, *and* control-port stuff to support any reasonable API for old vs new onion services (i.e. a .get_private_key() method or knowing what to do when the user changes something, like the ports list -- some are impossible to change, some need SETCONF, etc.) I believe I'm correct that the original use-case is to give a process control-port access but *not* read-access to the private-key, right? So this is fulfilled by doing "detach=true" to ADD_ONION (where you'll get back the onion but not the private key). Of course, then there is no way to re-start this hidden-service -- is that part of the use-case? I still feel like I don't really understand what problem the original use-case is trying to solve, though: "something" is creating some torrc changes and hidden-service dirs and then starting a thing that has control-port access. Could the original thing just pass in the service address to use?
Anyone who wants to open a ticket here, or has a counter argument? :)
As a *slight* counter-argument to adding on-disk services to the GETINFO, that would make it harder to distinguish between on-disk services and ADD_ONION -based ones. Not sure how much of a practical problem this is, though (worst-case would be that a controller would have to load all 'hostname' files to confirm which ones are on-disk vs. ADD_ONION). Perhaps a *third* GETINFO, e.g. "GETINFO onions/permanent" would be safest...? I have tried pretty hard to synthesize a unified API to "hidden services" (see release-1.x branch of txtorcon), and it's actually rather hard. So I'm not sure there's *any* value in trying to paper over the differences (at the control-protocol layer) by providing "one" API to get the hidden-service addresses -- any controller library is still going to need to distinguish all 6 flavours (permanent vs ephemeral, authenticated or not, stealth-auth or not). There's almost nothing completely common -- e.g. stealth-auth'd services have N onion-address, so there's not even "an" address. -- meejah
On Thu, 08 Sep 2016 22:44:42 +0400 meejah <meejah@meejah.ca> wrote:
Anyone who wants to open a ticket here, or has a counter argument? :)
As a *slight* counter-argument to adding on-disk services to the GETINFO, that would make it harder to distinguish between on-disk services and ADD_ONION -based ones. Not sure how much of a practical problem this is, though (worst-case would be that a controller would have to load all 'hostname' files to confirm which ones are on-disk vs. ADD_ONION). Perhaps a *third* GETINFO, e.g. "GETINFO onions/permanent" would be safest...?
Adding a third option would probably be the best, followed by extending the response syntax. As I said, the `GETINFO` stuff was added explicitly along and for the `ADD_ONION` command, with semantics to match. Regards, -- Yawning Angel
Well, this certainly triggered more conversation than I was expecting. I was simply wondering if there was such a method call, and apparently there isn't. That's okay. I thought about this and decided to go with Yawning's suggestion to just use ADD_ONION and then record the returned RSA private key. It's easy enough to add that same key back into Tor whenever I want. There are several main advantages with this route, including isolating my software's data from Tor's and requiring fewer modifications to torrc. It just seems cleaner in general. -- Jesse V
On Thu, Sep 08, 2016 at 07:16:26PM -0400, Jesse V wrote:
Well, this certainly triggered more conversation than I was expecting. I was simply wondering if there was such a method call, and apparently there isn't. That's okay.
I thought about this and decided to go with Yawning's suggestion to just use ADD_ONION and then record the returned RSA private key. It's easy enough to add that same key back into Tor whenever I want. There are several main advantages with this route, including isolating my software's data from Tor's and requiring fewer modifications to torrc.
How does ADD_ONION help with tor vs app data isolation? Why do you have to modify any torrc at all? Can't you do everything through the control port? I suppose there are many options not available via control port.
On 09/09/2016 04:23 AM, dawuud wrote:
How does ADD_ONION help with tor vs app data isolation? Why do you have to modify any torrc at all? Can't you do everything through the control port? I suppose there are many options not available via control port.
Under the old method I required the user to set up the hidden/onion service by adding a line to their torrc. That's not necessary if I used ADD_ONION. In both methods I still need them to enable the control port and an authentication, but it's just one less requirement using ADD_ONION. Data isolation is improved because it separates responsibility. In Linux, the tor binary runs under a separate user and sets up permissions to protect sensitive data. My OnioNS software can run as a separate user as well. This way, data is isolated to its respective software and I'm not mixing everything. -- Jesse V
Under the old method I required the user to set up the hidden/onion service by adding a line to their torrc. That's not necessary if I used ADD_ONION. In both methods I still need them to enable the control port
right. it shouldn't be necessary at all to modify the torrc... for most features.
and an authentication, but it's just one less requirement using ADD_ONION.
nah... you could use a unix domain socket instead of a TCP port and then just use filesystem permissions to limit access to the socket file. i much prefer this to authentication.
Data isolation is improved because it separates responsibility. In Linux, the tor binary runs under a separate user and sets up permissions to protect sensitive data. My OnioNS software can run as a separate user as well. This way, data is isolated to its respective software and I'm not mixing everything.
hmm ok well keep in mind an unfiltered contorl port is rather powerful and in a sense brings your software into the same security domain as the tor process. access to the control port can cause tor to execute a specified binary as a pluggable transports.
On 09/09/2016 10:15 PM, dawuud wrote:
right. it shouldn't be necessary at all to modify the torrc... for most features.
You need to modify the torrc in order to enable the ControlPort. https://github.com/Jesse-V/OnioNS-server/tree/json-rpc#setup
and an authentication, but it's just one less requirement using ADD_ONION. nah... you could use a unix domain socket instead of a TCP port and then just use filesystem permissions to limit access to the socket file. i much prefer this to authentication.
Good suggestion, I'll look into it. -- Jesse V
participants (5)
-
dawuud -
George Kadianakis -
Jesse V -
meejah -
Yawning Angel