[tor-dev] Embedding tor in an application and using tor without opening a port
Fabio Pietrosanti (naif)
lists at infosecurity.ch
Tue Apr 2 07:09:06 UTC 2013
On 4/2/13 12:09 AM, Nick Mathewson wrote:
> 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.
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
- If your application have strict signing requirements (for example on
- 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.
More information about the tor-dev