[tor-talk] Any risks with another application using Tor's SOCKS 5 interface?

James Marshall james at jmarshall.com
Thu Dec 5 00:51:18 UTC 2013


Thanks for the link to TBB's design document-- very useful.  I haven't read
it all, but I'm looking at section 2.2, "Privacy Requirements":

1) "Cross-Origin Identifier Unlinkability"-- so do sites with CORS or
Content-Security-Policy: not work through Tor?  CGIProxy supports CSP but
not CORS yet; I could add a flag to disable those two technologies.

2) "Cross-Origin Fingerprinting Unlinkability"-- this led me to read
section 3, "Adversary Model" and section 3.3, "Adversary Capabilities -
Attacks", and to review section 4, "Implementation".  CGIProxy handles some
but not all issues, but I believe it could be extended to cover the rest
(it can trap access to any JS or DOM property or method, for example).

3) "Long-Term Unlinkability"-- yeah, this has to be handled at the browser
end; fortunately, most browsers offer "private browsing" options, though I
imagine those would be disabled in a typical Internet cafe in China.

---------

By "install" Tor, I mean even copying a file.  This is relevant when e.g.
it's easier to transmit a URL than a piece of software to the user (via
radio/TV, via email when attachments are blocked, etc.).  Also, some users
may be wary of running Tor or another tool locally, if e.g. there's
monitoring software running (though this could arguably detect browser
accesses to sites with CGIProxy too).  Finally, even the minor trouble of
putting something on a USB stick might discourage some users.  Consider
that many (most?) in China don't care about being censored.  So I still
maintain that using CGIProxy is easier than installing and using anything
that requires software on the client side.

I'm also curious how Tor software gets into the hands of users in the first
place.  Hand-to-hand is best of course, but it seems like many users would
need something like CGIProxy or another circumvention tool to initially
obtain the Tor software.

Absolutely, a user of CGIProxy has to trust the proxy operator!  But the
same is true with Tor exit nodes too (except for SSL traffic), and there
the user has no chance to know the exit node operator.

Note that I'm not trying to pit CGIProxy against Tor.  I think they're very
different tools, and each is better in certain situations.  I see this as a
useful case of them working together, though, if any risks are ironed out.

Thanks again,
James



On Wed, Dec 4, 2013 at 1:05 PM, Moritz Bartl <moritz at torservers.net> wrote:

> On 04.12.2013 18:57, James Marshall wrote:
> > Is there any risk with another local application using Tor's SOCKS 5
> > interface?  I heard a vague comment that it wasn't recommended, but I
> > haven't heard exactly what the risks are, if any.
>
> Using a regular browser opens you to a lot of deanonymization attacks
> that Tor Browser does not. Read
> https://www.torproject.org/projects/torbrowser/design/ for more details.
>
> > This is for CGIProxy, which can use SOCKS 5 to provide a clientless
> > front-end to the Tor network (clientless in the sense that it doesn't
> > require an installation on the browsing machine).  This could
> significantly
> > increase the potential user base of Tor, since many users can't or don't
> > want to install anything on their browsing machine.
>
> You don't have to "install" Tor Browser, just extract to any directory
> you have write permission for. This can be a USB stick, or the home
> directory, or, if you can boot from a separate disk, Tails. So, everyone
> "can" install Tor Browser.
>
> With CGIProxy, you have to trust the operator of the cgi proxy, because
> it sees all traffic.
>
> --
> Moritz Bartl
> https://www.torservers.net/
> --
> tor-talk mailing list - tor-talk at lists.torproject.org
> To unsubscribe or change other settings go to
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>
>


More information about the tor-talk mailing list