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

[Roger Dingledine <arma@xxxxxxx>]

On Wed, Dec 04, 2013 at 04:51:18PM -0800, James Marshall wrote:
> 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.

These are good questions for the Tor Browser Team (Mike Perry, Georg
Koppen, and the Pearl Crescent folks). Mike and Georg are probably easiest
to find on irc (we're alas all overloaded these days with people trying
to contact us).

> 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.

Don't be confused into thinking that private browsing mode provides
protections against a network adversary (e.g. ISP, website, or ad
network). It has primarily to do with local storage.

You might also like Mike's paper, "Do Not Beg: Moving Beyond DNT through
Privacy by Design"
http://www.w3.org/2012/dnt-ws/position-papers/21.pdf

>   So I still
> maintain that using CGIProxy is easier than installing and using anything
> that requires software on the client side.

Yep. Can't argue with that.

> 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.

https://www.torproject.org/docs/faq#GetTor

https://svn.torproject.org/svn/projects/articles/circumvention-features.html#9

(The Gettor service is alas in need of some more love lately. Various
folks added a bunch of new features recently and then stopped working
on it right before everything became smooth.)

> 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.

I actually look at it in the opposite way: in the single-hop proxy case
(aka the VPN case) the proxy gets to learn both you and what you're
doing. In the distributed-trust case, even when you're not using
end-to-end encryption, the exit relay gets to know what *somebody* is
doing but doesn't necessarily get to learn who is doing it (or where in
the world the somebody is today).

https://svn.torproject.org/svn/projects/articles/circumvention-features.html#5
https://svn.torproject.org/svn/projects/articles/circumvention-features.html#7

> 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.

So the model is that somebody uses their browser to reach a cgiproxy
that's run somewhere else, and the cgiproxy runs its own Tor client
and passes its requests into Tor?

I think you want to be really careful about describing the security
properties you're aiming for there -- it isn't useless, but I worry that
it's easy for users to think they're getting "Tor" when actually they're
getting a single-hop proxy that can spy on them (plus also Tor).

--Roger

-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk