ID: 376PHID: PHID-TASK-dna54jtoxgwajatcwmd3Author: HulaHoopStatus at Migration Time: openPriority at Migration Time: Low
Proposal to add OnioNS-client the Tor-based DNS that supports secure, global and human memorable addresses, to Whonix Gateway when it supports using system-wide Tor and packaged for Debian.
opened 02:16PM - 10 Jul 15 UTC
closed 07:08PM - 17 Jul 15 UTC
enhancement
Jessie please keep designs like Whonix in mind where Tor is not running on the s… ame machine as TBB. There is a Gateway VM where Tor runs and where we plan to add OnioNS standalone package so it can process requests. What we'll need is a boolean setting for the OnioNS thats bundled with TBB so it can be disabled and only the instance on the gateway is used.
opened 07:07PM - 17 Jul 15 UTC
closed 02:26AM - 07 Aug 15 UTC
enhancement
Per [this ticket](https://github.com/Jesse-V/OnioNS-server/issues/53) OnioNS-cli… ent should use a flag to use a specific SOCKS port. That way the client can use 9150 for the Tor Browser, or 9050 for the generic system installation of Tor, allowing all applications to use OnioNS.
2015-07-25 18:24:38 UTC
quote Jesse Victors:
I’d be happy to explain. OnioNS-client opens 9053/TCP on localhost which listens for *.tor domains, and then writes *.onion back. A Python script, using Stem, receives event notifications through Tor’s control port of stream requests, picks up a *.tor domain lookup, sends it to 9053/TCP for resolution, reads back a *.onion address, tells Tor over the control port to redirect that stream to that *.onion address, and then tells Tor to attach that stream to a circuit. In effect, the Tor Browser operates exactly as before and from its perspective the user is browsing a *.tor domain, when under the hood Tor is receiving a *.onion lookup. This has the effect of loading hidden services under *.tor domain names.
OnioNS is mainly distributed through my Ubuntu PPA, as described in the README. My current approach for integrating with the Tor Browser is to rename the Tor executable in Browser/TorBrowser/Data to “torbin”, then insert my own executable which launches torbin, /usr/bin/onions-client, and the Python Stem script as child processes, in that order. That way, all the necessary software starts when the Tor Browser opens and by monitoring the status of torbin, they can all close when the Tor Browser closes as well. Obviously, this setup is not ideal and I do have plans to modify the Tor Launcher to also start up these processes, but my binary substitution approach was quicker and easier.
In summary, I’m not distributing a different build of the Tor Browser. Clients can still download and verify it via PGP and all that, but then they can get OnioNS functionality into it with a few rename and copy commands. That’s my current approach anyway. I’d love to integrate with Whonix of course, but I would like to prepare working binaries of non-Whonix software first, and then we can explore integrating with Whonix; one battle at a time. It’s entirely possible that it’ll be easy to integrate in Whonix, in which case we’ve killed two birds with one stone.
Alright. Sounds good. I’ll keep my time rereading this a few times over the next few days.
Seems like it’s two services. [as in (systemd) services to be started] (OnioNS-client + python script)
I guess we could just start OnioNS-client opens 9053/TCP on localhost and the python script in the workstation. When they try to reach Tor’s default SocksPort or Tor’s default ControlPort, those would be actually redirected to Whonix-Gateway (anon-ws-disable-stacked-tor). Good.
If OnioNS was provided by a Debian package, then the implementation might be as simple as installing the Debian package by default.
There is room to mess up the tor-launcher patch, though. If they would break the ability to not start Tor/OnioNS-client (export TOR_SKIP_LAUNCH=1). But that’s not very likely and we can give feedback in the process.
Even if there wasn’t a Debian package, then we might be able to provide instructions and/or a script and/or patch tb-starter, so it starts those two services from the extracted TBB. More hacky, fragile.
2016-07-30 23:34:54 UTC
2016-08-04 12:02:45 UTC
As of July, the latest commit was in February but revisions were made to the masters thesis published on github. So its not totally abandonware just under development.
EDIT:
Status update on OnioNS. Its alive and well going through refactoring:
[tor-dev] How to integrate an external name resolver into Tor
2016-08-22 00:31:36 UTC
2016-10-04 22:05:15 UTC