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 a...@mit.edu 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 security. If I'm missing something, then please let me know! Best, James -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Any risks with another application using Tor's SOCKS 5 interface?
On Wed, 4 Dec 2013 10:57:36 -0800 James Marshall ja...@jmarshall.com wrote: SOCKS 5 is insecure if the client and server are on different hosts and What exactly that insecurity consists of? If your aim is to open an client-less in-proxy to Tor network for anyone to use, then you might just as well open your SOCKS 5 port to the world. AFAIK any insecurity in SOCKS is related only to authentication, i.e. unauthorized users may be able to connect to your SOCKS proxy. But that's not an issue if you open it to anyone by design anyway. -- With respect, Roman signature.asc Description: PGP signature -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Any risks with another application using Tor's SOCKS 5 interface?
Thanks for the response. SOCKS 5 insecurity: If you use username/password authentication (as Tor does), the username and password are sent in the clear. That's one reason not to open the SOCKS 5 port to the world. Another reason might be that a user is unable to modify proxy settings, e.g. in an Internet cafe. I've never used GSSAPI authentication, but my understanding is that SOCKS 5 is secure if you use it. Corrections always welcome. Cheers, James On Wed, Dec 4, 2013 at 11:40 AM, Roman Mamedov r...@romanrm.net wrote: On Wed, 4 Dec 2013 10:57:36 -0800 James Marshall ja...@jmarshall.com wrote: SOCKS 5 is insecure if the client and server are on different hosts and What exactly that insecurity consists of? If your aim is to open an client-less in-proxy to Tor network for anyone to use, then you might just as well open your SOCKS 5 port to the world. AFAIK any insecurity in SOCKS is related only to authentication, i.e. unauthorized users may be able to connect to your SOCKS proxy. But that's not an issue if you open it to anyone by design anyway. -- With respect, Roman -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Any risks with another application using Tor's SOCKS 5 interface?
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@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Any risks with another application using Tor's SOCKS 5 interface?
On 12/04, 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. How else would any application access the Tor network? This is exactly how, e.g., Firefox in the Tor Browser Bundle works -- by pointing it at Tor's SOCKS5 proxy. If you want to use additional applications, you might edit torrc so that Tor listens on additional ports. IIUC, each one of those will build/use separate circuits. I don't remember where but I recall coming across suggestions to do just that -- use different ports -- for various applications (e.g. one port for your browser, a different port for your mail client, yet another for an IRC client, and so on). -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Any risks with another application using Tor's SOCKS 5 interface?
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 mor...@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@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Any risks with another application using Tor's SOCKS 5 interface?
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@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
