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