Embedding tor in an application and using tor without opening a port
I am making a small application that always uses tor to communicate. I have embedded tor into the application by compiling and linking the tor source code along with my own code and calling tor's main() from within my own main(). To send data, tor has to open a port on the machine and my application would have to send data to 127.0.0.1:port This seems a little unnecessary since both tor and my application run in the same process. More importantly, it seems like any program on the machine can use my application's embedded tor client by connecting to the right port. The easiest way to avoid opening a port seems to be to modify the socket implementation so that it accesses an array rather than sending/receiving data. Are there any existing applications that embed tor in this manner? Is there a better way to do this, and if not, are there any corner cases I have to watch out for?
On 4/1/13 10:17 PM, Navin Francis wrote:
You may consider the discussion on "Using Tor as a Library" on Tor-dev in past week about the idea to make Tor be able to work as a library: https://lists.torproject.org/pipermail/tor-dev/2013-March/004564.html https://lists.torproject.org/pipermail/tor-dev/2013-March/004571.html Let's Cc Waldo that's working on that concept. Fabio
On Mon, Apr 1, 2013 at 4:17 PM, Navin Francis <navin.kurupacheril@gmail.com> wrote:
Are there any existing applications that embed tor in this manner?
This is pretty much unsupported for the reasons discussed in https://lists.torproject.org/pipermail/tor-dev/2010-November/002141.html and https://lists.torproject.org/pipermail/tor-talk/2011-September/021529.html among others. My preferred approach for applications that want to include their own Tor would be to have a library (perhaps based on Torsocks) that handles making connections over Tor, plus maybe another library that would find a running Tor or launch one as needed. That way we wouldn't have a huge pile of apps all stuck downloading their own directory information, and we wouldn't wind up with a bunch of forked Tor versions all diverging independently. Nonetheless, people keep wanting to do it the way you suggest, and it's free software, so do what you like. best wishes, -- Nick
Nick Mathewson <nickm@alum.mit.edu> writes:
[..] plus maybe another library that would find a running Tor or launch one as needed.
Are there ideas/designs written down for this anywhere? I am interested in seeing this happen -- I took a very quick stab at it in txtorcon but realized it would be Much Better if this had co-operation from Tor processes running on the system. For controllers, the use-case would likely be to present a user with choices (e.g. "use one of these Tors I found running, or launch a new one?") or for a "please give me an anonymous socket, whatever that takes" sort of function (which could try using a running tor first, if allowed). Trying to enumerate via process inspection or netstat-like ways is likely not the good way forward... -- meejah
On Mon, Apr 1, 2013 at 6:49 PM, meejah <meejah@meejah.ca> wrote:
Not AFAIK. I think that any solution here is likely to be platform-specific, and require careful security analysis. I'm afraid I don't know much about the state of desktop IPC these days, but I hope others will be able to come up with something sensible here. -- Nick
Arm needed a capability like this so it can provide useful messaging (ie "Tor isn't running" vs "Tor's running, but without a control port"). This is done via the 'get_pid_by_*' methods in stem's system module... https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/util/system.py Is that the sort of thing that you're looking for? -Damian
On 4/2/13 12:09 AM, Nick Mathewson wrote:
While i understand that you do not like this solution we should also acknowledge that there are several condition where "running an independent process" is just not an option and, not having a Tor as a library, represent a limitation. By design it's required/better to have tor built as a part of the application in the following conditions for example: - if you need to deploy a "Single executable" - if, for security reason, you need a unique application update system - if your application can't startup other applications (for example on App Stores) - If your application have strict signing requirements (for example on App Stores) - if you need a forensically proof application (not writing file around, not being able to use kernel-level disk encryption) - If you can't open listening port on the specific system due to permissions - if you need to do filesystem i/o only on a single application's database file (like a sqlite) If we would have Tor also workable as a library, IMHO we would have a clean-by-design-from-software-engineering-point-of-view way to use Tor. Fabio
participants (5)
-
Damian Johnson -
Fabio Pietrosanti (naif) -
meejah -
Navin Francis -
Nick Mathewson