Hi Folks:
I am looking to use Tor as a library for my program. I managed to build it from the sources including the required libraries. But now I am looking for hints on how to replace the SOCKS 4/5 or the transparent proxy with direct calls from my application to link them. I'm hoping somebody here can point me in the right direction. That is turning off all listening for incoming connections. Just my application going through tor circuits.
I am looking not only to send/receive data over tor (looks I can do this touching connection_edge.c) but also to get callbacks reporting connection status (looks I have to change control_event_circuit_status and control_event_circuit_status_minor) and pass configuration data directly instead of loading from a configuration file (seems I have to call set_options at config.c with prefilled or_options_t structure). Just guessing.
Regards Waldo
On 3/28/13 8:32 AM, wac wrote:
Hi Folks:
I am looking to use Tor as a library for my program. I managed to build it from the sources including the required libraries. But now I am looking for hints on how to replace the SOCKS 4/5 or the transparent proxy with direct calls from my application to link them. I'm hoping somebody here can point me in the right direction. That is turning off all listening for incoming connections. Just my application going through tor circuits.
That's the future of Tor, to be integrated as a library just like an encryption library into application.
That's also the only way to make applications in constrained environment, such as Apple iOS.
Some useful link to look at is: https://github.com/mtigas/iOS-OnionBrowser (embedding Tor as part of Apple iOS application) https://lists.torproject.org/pipermail/tor-talk/2011-September/021527.html
If you approach this kind of problem, it would great if you create a full set of patches, creating proper tickets on http://trac.torproject.org and detailed documentation to enable anyone to build "Applications" with Tor built-in in an easy way.
A very valuable target could be to create a "wrapper" around Tor with minor patch to be able to use it as a library from any major application programming languages.
Fabio
"Fabio Pietrosanti (naif)" lists-BEJ3GKOyH/EwUp2xcto6ig@public.gmane.org writes:
That's the future of Tor, to be integrated as a library just like an encryption library into application.
No, it's not. Embedding a Tor client in another application cripples auditability, configurability, updateability etc. of Tor. So does embedding a controller. Even worse, an application trying to outsmart the user by controlling Tor on its own poses a severe security risk.
Other than an encryption library, there is no well-defined output to an input that a Tor library should produce.
Tor is a vivid, organic ecosystem of different, replaceable projects that integrate into each other. Embedding a static subset of these in an application is wrong.
Christopher
On 28.03.2013 12:10, Christopher Schmidt wrote:
"Fabio Pietrosanti (naif)" lists-BEJ3GKOyH/EwUp2xcto6ig@public.gmane.org writes:
That's the future of Tor, to be integrated as a library just like an encryption library into application.
No, it's not. Embedding a Tor client in another application cripples auditability, configurability, updateability etc. of Tor.
Yes. Still, there is "Netlib", https://silvertunnel.org/ , and some people are working on a revived JTor (client and relay), https://github.com/koryk/JTor . Also, Briar showed some interest in embedding Tor.
Additional implementations of the Tor protocols help to improve documentation, and code bugs/vulnerabilities won't affect all of Tor.
Christopher Schmidt christopher@ch.ristopher.com wrote:
"Fabio Pietrosanti (naif)" lists-BEJ3GKOyH/EwUp2xcto6ig@public.gmane.org writes:
That's the future of Tor, to be integrated as a library just like an encryption library into application.
No, it's not. Embedding a Tor client in another application cripples auditability, configurability, updateability etc. of Tor. So does embedding a controller. Even worse, an application trying to outsmart the user by controlling Tor on its own poses a severe security risk.
Other than an encryption library, there is no well-defined output to an input that a Tor library should produce.
Tor is a vivid, organic ecosystem of different, replaceable projects that integrate into each other. Embedding a static subset of these in an application is wrong.
On Android, we have developed a library that allows a 3rd party developer's app to check if Orbot (and by extension Tor) is installed and running, and if either is false provides methods to prompt the user to resolve both false states. We also provide simple code for properly proxying app data through SOCKS.
Perhaps a similar approach could be taken for desktop and server apps that want to integrate with Tor?
On 3/28/13 12:10 PM, Christopher Schmidt wrote:
"Fabio Pietrosanti (naif)" lists-BEJ3GKOyH/EwUp2xcto6ig@public.gmane.org writes:
That's the future of Tor, to be integrated as a library just like an encryption library into application.
No, it's not. Embedding a Tor client in another application cripples auditability, configurability, updateability etc. of Tor. So does embedding a controller. Even worse, an application trying to outsmart the user by controlling Tor on its own poses a severe security risk.
It completely disagree with that vision. A separate component can be tampered or misconfiguredwithout leveraging the specific application context of use. A separate component cannot leverage the efficient automatic-update procedures of a specific application using it.
Other than an encryption library, there is no well-defined output to an input that a Tor library should produce.
The input and output is so very well defined that there's an RFC 1928 defining it.
Without a tight integration with an application there are additional risks, such as applications "leaking DNS" or "connecting directly if Socks server is not available" .
Without direct application integration (linking tor with the application) there is *much more code and complexity involved* and this represent a risks for the end-user.
Tor is a vivid, organic ecosystem of different, replaceable projects that integrate into each other. Embedding a static subset of these in an application is wrong.
The same for major crypto library like OpenSSL, but all applications link it directly rather than using an outdated IPC mechansmis here called "SOCKS" (involving multiple layers of software in userspace and kernel-space to be used).
From the software architectural and security perspective having Tor
integrated within an application represent a security advantage for the end-user, imho without any doubt.
Fabio
-
Christopher Schmidt -
Fabio Pietrosanti (naif) -
Moritz Bartl -
Nathan Freitas -
wac