[tor-dev] Using Tor as a library
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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Using Tor as a library
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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [tor-talk] Mobile Anonymity and Circumvention seems not working
Does the "check.torproject.org" site return a connected message in the default browser? chandra mohan wrote: >Hi, > > I tried Trasparent proying of Orbot as mentioned >https://guardianproject.info/apps/orbot/->OTHER >*APPS* and observed all web (traffic built-in Browser, Gmail, YouTube, >Maps and any other application >that uses standard web traffic)and all DNS requests from my Android >mobile >are not following Tor >encryprtion. > > Observed with wireshark and above mentioned application traffics >are having DNS request and DNS >response packets and followed by large number of HTTP packets. > > My Mobile is running on Android 2.2 Kernel which is already root >and I also gave super user >permission for Tor installation. > > what is possibe issue here? > >Regards, >Chandramohan >___ >tor-talk mailing list >tor-t...@lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Using Tor as a library
"Fabio Pietrosanti (naif)" 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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Using Tor as a library
On 28.03.2013 12:10, Christopher Schmidt wrote: > "Fabio Pietrosanti (naif)" > 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. -- Moritz Bartl https://www.torservers.net/ ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Using Tor as a library
Christopher Schmidt wrote: >"Fabio Pietrosanti (naif)" > 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? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Using Tor as a library
On 3/28/13 12:10 PM, Christopher Schmidt wrote: > "Fabio Pietrosanti (naif)" > 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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Using Tor as a library
Hi Fabio Pietrosanti: Thanks, I appreciate your help. I will be working on this. I actually was considering to maybe provide it to the community so people could pinpoint bugs and contribute patches. I will be studying onionbrowser. But seems they are running Tor as a thread inside the browser executing tor_main and then have the browser connect to itself using socks 5 which is somehow ugly. This looked interesting: https://lists.torproject.org/pipermail/tor-talk/2011-September/021528.html but seems Tor just evolved. > That's the future of Tor, to be integrated as a library just like an > encryption library into application. Same feeling here. Thanks for your comments Christopher Schmidt. I do appreciate to hear different points of view and know beforehand feelings of people against. Yet I disagree and I would like to argument why. >Embedding a Tor client in another application cripples >auditability, configurability, updateability etc. of Tor. Not necessarily. If it is open source would be auditable. I could dynamically link the library to let you update it on your own if you want. Also the application can be updated. But even if statically linked and not updated as the Tor network evolves the application would become unusable if the standard changes therefore killing the insecure application eventually. Regarding configurability I could proxy your configuration to the Tor library. Since it is open you can check I am being honest or if there are bugs even if such application is not open source. (you could even override received configuration from the application) I could let you configure the application to use embedded Tor or not, then you could use your own tor client if you want. And this is not entirely clear to me but I believe Tor could be routed trough Tor again if you are forced to use embedded library and you are worried about it being insecure. And in any case well you can opt in or out of the application. Yet as a library I believe there would be increase of useability. That means Tor will be more popular. If it becomes more popular it means more support. I mean I probably wouldn't be donating a relay to the network If I weren't using Tor. > Even worse, an application trying to outsmart >the user by controlling Tor on its own poses a severe security risk. Well an application using Tor as it is and properly configured could create a covert channel and totally do away with your anonymity. So I am supposing the application is not intentionally evil. >From another standpoint every security chain is as strong as its weakest link. >Usually the weak link is the user miss-configuring things and then comes the >false sense of security. As Fabio pointed earlier the DNS leak or the direct connection for example. In any case if you want to provide arguments against I would like to hear them. I tell you what. I don't have intentions to change Tor. I basically want to do this for me. But since I notice now it could be useful to the community and the community could be providing feedback I can make it public under the same license. So this is what I am going to do. Fork Tor under the same license and change it until I get a working library. If somebody wants to join well everybody invited. I think more hands working on it will be great. And if you want to merge it with Tor well you all can decide that later. And if you want we can cooperate directly. After all both projects would be sharing a lot of sourcecode. Many fixes and optimizations will be able to come back to Tor and the library could receive updates from the Tor project. I am thinking to name it libtor. What do you say? I think a good approach could be to start with the ugly hack creating a clean API that would get extended over time and then change bit by bit until we get something clean. Regards Waldo ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev