Idea regarding active probing and follow-up of SSL connections to TOR bridges
Hi, I've just watched https://www.youtube.com/watch?v=GwMr8Xl7JMQ (old, I know), and found it very interesting. Also, before going any further, I'd like to stress that I'm new to tor-dev and while I've googled my question, I haven't been able to come up with anything, so apologies in advance if this is already solved. Anyway, one of the main topics discussed in that talk was the problem of preventing the blockage of TOR bridges by oppressors. While many "fixes" were mentioned, none of them actually solve the problem of the bridge being probed, by following-up on previously captured SSL sessions (as China does). I was thinking - perhaps instead of making the discovery of the actual bridge addresses "hard", why not setup bridges in places where other *legitimate* SSL connections are also made? What I mean is, maybe we should try and get big sites that cannot be legitimately (in the eyes of the oppressor, of course) blocked (social media, comic sites, whatever), to run a TOR bridge *on the same port* as their regular HTTPS traffic (443), in a way that someone recording the traffic cannot distinguish (in advance, that is) whether a certain SSL connection to that site is a legitimate web browsing session, or a TOR session. That way, even if an address on the internet "speaks" the TOR protocol, it cannot be automatically blocked. Even if this address is known to host a TOR bridge, this might help plausible deniability for people unwilling to disclose that they've been using TOR. I understand this is probably very difficult, for several reasons, but I will try to address some of these. First off - there's the technical issue of binding to port 443 locally on the web servers without disrupting the currently running local client. I see several possible ways around this - a simple one could be local proxying of the SSL connection from the TOR bridge software to the locally running web server, in a way that when the bridge gets an SSL connection that isn't "speaking" the TOR protocol, it will be handed over to the web server. I admit, it's kinda messy, but TBH there are probably more efficient and "cleaner" ways to do this than what I've suggested. Also, long running connections with heavy data usage to a web server address are probably suspicious, but even if these were to be blocked, it would be on a per-client basis, and would also just mean a QoS issue for users but not DoS. Lastly, there's the question of why would a large site agree to this. I still don't have a good answer for this, but maybe you do... (PR, perhaps?) Anyway, I'd like to hear what you think. Maybe this isn't an issue anymore, or maybe you've found a different solution, or mine doesn't work, or you've already implemented it, etc. :) laginimaineb.
On Sat, Jul 06, 2013 at 09:34:06PM +0300, Lag Inimaineb wrote:
Anyway, one of the main topics discussed in that talk was the problem of preventing the blockage of TOR bridges by oppressors. While many "fixes" were mentioned, none of them actually solve the problem of the bridge being probed, by following-up on previously captured SSL sessions (as China does).
Since then, several systems were proposed which should solve this problem. First, there is DEFIANCE [0]. I believe that people are working on an implementation but I don't have more information. There's also ScrambleSuit [1] which is an obfsproxy module and protects against active probing by requiring a shared secret which is distributed out-of-band (e.g., over bridgedb). We have a working prototype of ScrambleSuit and we would highly appreciate code review.
I was thinking - perhaps instead of making the discovery of the actual bridge addresses "hard", why not setup bridges in places where other legitimate SSL connections are also made? What I mean is, maybe we should try and get big sites that cannot be legitimately (in the eyes of the oppressor, of course) blocked (social media, comic sites, whatever), to run a TOR bridge on the same port as their regular HTTPS traffic (443), in a way that someone recording the traffic cannot distinguish (in advance, that is) whether a certain SSL connection to that site is a legitimate web browsing session, or a TOR session. That way, even if an address on the internet "speaks" the TOR protocol, it cannot be automatically blocked. Even if this address is known to host a TOR bridge, this might help plausible deniability for people unwilling to disclose that they've been using TOR.
There are some proposals which suggest to tunnel Tor traffic over "legitimate" protocols to increase collateral damage when blocked. That includes FreeWave, Code Talker Tunnel (a.k.a. SkypeMorph) and SWEET. These projects can partially defend against active probing because of their underlying protocols (SSL-based email, Skype, VoIP). Unfortunately, none of these proposals are close to being deployed. SkypeMorph does have a prototype, though.
First off - there's the technical issue of binding to port 443 locally on the web servers without disrupting the currently running local client. I see several possible ways around this - a simple one could be local proxying of the SSL connection from the TOR bridge software to the locally running web server, in a way that when the bridge gets an SSL connection that isn't "speaking" the TOR protocol, it will be handed over to the web server. I admit, it's kinda messy, but TBH there are probably more efficient and "cleaner" ways to do this than what I've suggested.
There's a Tor proposal which suggests something quite similar [2]. There's no implementation of it, though. [0] https://www.usenix.org/system/files/conference/foci12/foci12-final7.pdf [1] http://www.cs.kau.se/philwint/scramblesuit/ [2] https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/203-https-fro... Cheers, Philipp
Thanks for your response, I'm glad to hear this problem is still interesting :). Specifically, after reading Nick Mathewson's proposal, I can see it is pretty much identical to what I've proposed (though his proposal has been around for more than a year). Do you have any information as to whether anyone has been/is working on implementing it? As for suggestions such as SWEET, FreeWave, etc. - those would require changes to the TOR clients (right?), which makes them probably less easy to use, unless they are merged into the TOR mainline. Same goes for ScambleSuit, since the shared secret much somehow be delivered out-of-band, which is not always an easy feat to accomplish. On Sat, Jul 27, 2013 at 3:53 PM, Philipp Winter <identity.function@gmail.com
wrote:
On Sat, Jul 06, 2013 at 09:34:06PM +0300, Lag Inimaineb wrote:
Anyway, one of the main topics discussed in that talk was the problem of preventing the blockage of TOR bridges by oppressors. While many "fixes" were mentioned, none of them actually solve the problem of the bridge being probed, by following-up on previously captured SSL sessions (as China does).
Since then, several systems were proposed which should solve this problem. First, there is DEFIANCE [0]. I believe that people are working on an implementation but I don't have more information. There's also ScrambleSuit [1] which is an obfsproxy module and protects against active probing by requiring a shared secret which is distributed out-of-band (e.g., over bridgedb). We have a working prototype of ScrambleSuit and we would highly appreciate code review.
I was thinking - perhaps instead of making the discovery of the actual bridge addresses "hard", why not setup bridges in places where other legitimate SSL connections are also made? What I mean is, maybe we should try and get big sites that cannot be legitimately (in the eyes of the oppressor, of course) blocked (social media, comic sites, whatever), to run a TOR bridge on the same port as their regular HTTPS traffic (443), in a way that someone recording the traffic cannot distinguish (in advance, that is) whether a certain SSL connection to that site is a legitimate web browsing session, or a TOR session. That way, even if an address on the internet "speaks" the TOR protocol, it cannot be automatically blocked. Even if this address is known to host a TOR bridge, this might help plausible deniability for people unwilling to disclose that they've been using TOR.
There are some proposals which suggest to tunnel Tor traffic over "legitimate" protocols to increase collateral damage when blocked. That includes FreeWave, Code Talker Tunnel (a.k.a. SkypeMorph) and SWEET. These projects can partially defend against active probing because of their underlying protocols (SSL-based email, Skype, VoIP).
Unfortunately, none of these proposals are close to being deployed. SkypeMorph does have a prototype, though.
First off - there's the technical issue of binding to port 443 locally on the web servers without disrupting the currently running local client. I see several possible ways around this - a simple one could be local proxying of the SSL connection from the TOR bridge software to the locally running web server, in a way that when the bridge gets an SSL connection that isn't "speaking" the TOR protocol, it will be handed over to the web server. I admit, it's kinda messy, but TBH there are probably more efficient and "cleaner" ways to do this than what I've suggested.
There's a Tor proposal which suggests something quite similar [2]. There's no implementation of it, though.
[0] https://www.usenix.org/system/files/conference/foci12/foci12-final7.pdf [1] http://www.cs.kau.se/philwint/scramblesuit/ [2] https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/203-https-fro...
Cheers, Philipp _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 27 July 2013 10:17, Lag Inimaineb <laginimaineb@gmail.com> wrote:
As for suggestions such as SWEET, FreeWave, etc. - those would require changes to the TOR clients (right?), which makes them probably less easy to use, unless they are merged into the TOR mainline. Same goes for ScambleSuit, since the shared secret much somehow be delivered out-of-band, which is not always an easy feat to accomplish.
Those are not the biggest hurdles. Distributing a secret along with bridge IPs is not too difficult, BridgeDB has this capability built in. Likewise, changes to TBB are relatively easy compared to the difficulty of having a major social media site install software that splits Tor bridge traffic off from their legit HTTP traffic. That would require them being extremely, _extremely_ confident in the scalability, performance, and security of said code. That said - I've had this same idea myself. I tend to categorize censorship into 4 buckets: 1) Source-Based. You are not allowed online. 2) Destination-Based - you can't talk to this host, this IP, this port 3) Byte-Matching - You can't search for this term, you can't speak this protocol 4) Pattern-Based - You can't talk SSL in a manner where you're uploading the same amount as you're downloading, or you can't use SSH in a way that looks like you're transferring files. We've seen large deployments of Destination-Based and Byte-Matching (and augmented w/ follow-up scans to have a higher confidence). Github was blocked in China briefly, and allegedly the Chinese people protested and the ban was lifted.[0] This implies, to me, that certain sites are too politically important to be blocked. If we enlisted their help in this model we would have essentially unblockable bridges. It's a win-win: Either the gov't doesn't block the site, and people can use the bridges OR The gov't does block the site, piss people off, and hopefully begins the crumble. It's probably not a popular opinion, but the more the government makes a people suffer... the more likely they are to overthrow it. (And not having github is a lot better suffering than being thrown in the gulag.) -tom [0] http://www.h-online.com/open/news/item/GitHub-blocked-in-China-Update-178911...
On Sat, Jul 27, 2013 at 05:17:29PM +0300, Lag Inimaineb wrote:
Specifically, after reading Nick Mathewson's proposal, I can see it is pretty much identical to what I've proposed (though his proposal has been around for more than a year). Do you have any information as to whether anyone has been/is working on implementing it?
I'm not aware of anyone doing that. I believe, it was a potential GSoC project but nobody had the time to mentor it. See also: https://www.torproject.org/getinvolved/volunteer.html.en#httpsImpersonation
As for suggestions such as SWEET, FreeWave, etc. - those would require changes to the TOR clients (right?), which makes them probably less easy to use, unless they are merged into the TOR mainline. Same goes for ScambleSuit, since the shared secret much somehow be delivered out-of-band, which is not always an easy feat to accomplish.
Not necessarily. The idea of obfsproxy is to put circumvention functionality into a separate program and let Tor only do what it does best: provide anonymity. Besides, the circumvention race is a quick one and obfsproxy makes it possible for us to (semi-)quickly deploy novel circumvention protocols. Also, because it makes use of Python which is more pleasant for experimental protocols than C. Nevertheless, as you say, many of these protocols require changes to obfsproxy or completely new frameworks. Regarding ScrambleSuit's shared secret: some parts in the Tor world must be changed but we are working on it. For more details, please see: https://trac.torproject.org/projects/tor/ticket/8979 https://trac.torproject.org/projects/tor/ticket/9013 Cheers, Philipp
I have some catching up to do on obfsproxy :). I think obviously agility in pushing out these kinds of solutions is very important, so making a separate python client sounds like a great idea. As for TLS handshake profiling - well, that was also discussed in the original video, but as that video mentions, this is solvable by imitating (closely enough) a legitimate client. Actually, come to think of it, is there a licensing issue in using Chromium TLS code (which is open-source and probably very common, as Chrome is quite a popular browser) in TOR? On Sat, Jul 27, 2013 at 6:47 PM, Philipp Winter <identity.function@gmail.com
wrote:
On Sat, Jul 27, 2013 at 05:17:29PM +0300, Lag Inimaineb wrote:
Specifically, after reading Nick Mathewson's proposal, I can see it is pretty much identical to what I've proposed (though his proposal has been around for more than a year). Do you have any information as to whether anyone has been/is working on implementing it?
I'm not aware of anyone doing that. I believe, it was a potential GSoC project but nobody had the time to mentor it. See also: https://www.torproject.org/getinvolved/volunteer.html.en#httpsImpersonation
As for suggestions such as SWEET, FreeWave, etc. - those would require changes to the TOR clients (right?), which makes them probably less easy to use, unless they are merged into the TOR mainline. Same goes for ScambleSuit, since the shared secret much somehow be delivered out-of-band, which is not always an easy feat to accomplish.
Not necessarily. The idea of obfsproxy is to put circumvention functionality into a separate program and let Tor only do what it does best: provide anonymity. Besides, the circumvention race is a quick one and obfsproxy makes it possible for us to (semi-)quickly deploy novel circumvention protocols. Also, because it makes use of Python which is more pleasant for experimental protocols than C.
Nevertheless, as you say, many of these protocols require changes to obfsproxy or completely new frameworks. Regarding ScrambleSuit's shared secret: some parts in the Tor world must be changed but we are working on it. For more details, please see: https://trac.torproject.org/projects/tor/ticket/8979 https://trac.torproject.org/projects/tor/ticket/9013
Cheers, Philipp _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
participants (3)
-
Lag Inimaineb -
Philipp Winter -
Tom Ritter