[tor-dev] Using Tor as a library

[Fabio Pietrosanti (naif)]

On 3/28/13 12:10 PM, Christopher Schmidt wrote:
> "Fabio Pietrosanti (naif)" <lists-BEJ3GKOyH/EwUp2xcto6ig at 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