[tor-dev] Using Tor as a library

2013-03-28 Thread wac

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

2013-03-28 Thread Fabio Pietrosanti (naif)
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

2013-03-28 Thread Nathan Freitas
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

2013-03-28 Thread Christopher Schmidt
"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

2013-03-28 Thread Moritz Bartl
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

2013-03-28 Thread Nathan Freitas


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

2013-03-28 Thread Fabio Pietrosanti (naif)
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

2013-03-28 Thread wac

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