[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

On Wed, Dec 4, 2013 at 8:17 PM, Roger Dingledine <arma@xxxxxxx> wrote:

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

No worries, I understand that.  I was just responding to the text in that
section, which seems to be just about 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

Interesting, thanks.  I absolutely agree that self-regulation as a
principle doesn't work, in this case the self-regulation by servers.  One
of the biggest points of anonymity is to deal with a potentially malicious
server, after all.

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

Yeah, I think Tor and CGIProxy each address privacy in fundamentally
different ways.  CGIProxy relies on trust between the user and the proxy
owner, and Tor tries to be safe without that trust relationship.

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

Yes, that's exactly the model.  Like I say, for some potential users it's
easier to obtain a URL than a software package.

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

Since the beginning, CGIProxy has relied on a trust relationship between
the user and proxy owner (though I haven't always made that as clear as I
should have).  The idea is that there are many independent instances of
CGIProxy running, each serving a circle of trusted people.  So if we assume
that trust, then the proxy owner won't spy on the users.

If we're talking about a large circumvention network using CGIProxy (e.g.
run by some company or NGO), then the proxy owner may be a stranger to the
user, and the trust relationship relies on the good public reputation of
that proxy owner.

This doesn't guard against spies breaking into the server and replacing
CGIProxy with malware; that's a problem with just about all (?) forms of
proxies, though I think Tor is much safer from this than the rest because
of its multi-hop approach.  But yeah, proxy privacy relies on server

If I'm missing something, then please let me know!

tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to