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.
https://github.com/Jesse-V/OnioNS-server/issues/53
https://github.com/Jesse-V/OnioNS-client/issues/14
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.
This task should take a backseat indefinitely. The OnioNS project is unfinished and undeployed:
https://lists.torproject.org/pipermail/tor-dev/2016-July/011241.html
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:
https://lists.torproject.org/pipermail/tor-dev/2016-August/011265.html
TPO devs going back to the drawing board since no optimal human readable address solution exists. They are giving it priority since longer HS addresses are just around the corner.
https://lists.torproject.org/pipermail/tor-dev/2016-August/011314.html
https://trac.torproject.org/projects/tor/wiki/doc/OnionServiceNamingSystems
Jesse has improved OnioNS a lot since the GSoC release. Submitted updated paper and design to PoPETS. Tor has not decided to rely on a single official easy name resolution solution yet however a name resolution agnostic API supported by Tor is planned and proposals soon suggested.
https://lists.torproject.org/pipermail/tor-dev/2016-October/011494.html
https://lists.torproject.org/pipermail/tor-dev/2016-October/011495.html