<div dir="ltr"><div>Thanks for your response, I'm glad to hear this problem is still interesting :). <br><br></div>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?<br>
<br>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.<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 27, 2013 at 3:53 PM, Philipp Winter <span dir="ltr"><<a href="mailto:identity.function@gmail.com" target="_blank">identity.function@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sat, Jul 06, 2013 at 09:34:06PM +0300, Lag Inimaineb wrote:<br>
> Anyway, one of the main topics discussed in that talk was the problem of<br>
> preventing the blockage of TOR bridges by oppressors. While many "fixes" were<br>
> mentioned, none of them actually solve the problem of the bridge being<br>
> probed, by following-up on previously captured SSL sessions (as China does).<br>
<br>
</div>Since then, several systems were proposed which should solve this problem.<br>
First, there is DEFIANCE [0]. I believe that people are working on an<br>
implementation but I don't have more information. There's also ScrambleSuit<br>
[1] which is an obfsproxy module and protects against active probing by<br>
requiring a shared secret which is distributed out-of-band (e.g., over<br>
bridgedb). We have a working prototype of ScrambleSuit and we would highly<br>
appreciate code review.<br>
<div class="im"><br>
> I was thinking - perhaps instead of making the discovery of the actual bridge<br>
> addresses "hard", why not setup bridges in places where other legitimate SSL<br>
> connections are also made? What I mean is, maybe we should try and get big<br>
> sites that cannot be legitimately (in the eyes of the oppressor, of course)<br>
> blocked (social media, comic sites, whatever), to run a TOR bridge on the<br>
> same port as their regular HTTPS traffic (443), in a way that someone<br>
> recording the traffic cannot distinguish (in advance, that is) whether a<br>
> certain SSL connection to that site is a legitimate web browsing session, or<br>
> a TOR session. That way, even if an address on the internet "speaks" the TOR<br>
> protocol, it cannot be automatically blocked. Even if this address is known<br>
> to host a TOR bridge, this might help plausible deniability for people<br>
> unwilling to disclose that they've been using TOR.<br>
<br>
</div>There are some proposals which suggest to tunnel Tor traffic over "legitimate"<br>
protocols to increase collateral damage when blocked. That includes FreeWave,<br>
Code Talker Tunnel (a.k.a. SkypeMorph) and SWEET. These projects can<br>
partially defend against active probing because of their underlying protocols<br>
(SSL-based email, Skype, VoIP).<br>
<br>
Unfortunately, none of these proposals are close to being deployed. SkypeMorph<br>
does have a prototype, though.<br>
<div class="im"><br>
> First off - there's the technical issue of binding to port 443 locally on the<br>
> web servers without disrupting the currently running local client. I see<br>
> several possible ways around this - a simple one could be local proxying of<br>
> the SSL connection from the TOR bridge software to the locally running web<br>
> server, in a way that when the bridge gets an SSL connection that isn't<br>
> "speaking" the TOR protocol, it will be handed over to the web server. I<br>
> admit, it's kinda messy, but TBH there are probably more efficient and<br>
> "cleaner" ways to do this than what I've suggested.<br>
<br>
</div>There's a Tor proposal which suggests something quite similar [2]. There's no<br>
implementation of it, though.<br>
<br>
[0] <a href="https://www.usenix.org/system/files/conference/foci12/foci12-final7.pdf" target="_blank">https://www.usenix.org/system/files/conference/foci12/foci12-final7.pdf</a><br>
[1] <a href="http://www.cs.kau.se/philwint/scramblesuit/" target="_blank">http://www.cs.kau.se/philwint/scramblesuit/</a><br>
[2] <a href="https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/203-https-frontend.txt" target="_blank">https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/203-https-frontend.txt</a><br>
<br>
Cheers,<br>
Philipp<br>
_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
</blockquote></div><br></div>