<div dir="ltr"><div>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. <br><br>
</div>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?<br>

<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Jul 27, 2013 at 6:47 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 27, 2013 at 05:17:29PM +0300, Lag Inimaineb wrote:<br>
> Specifically, after reading Nick Mathewson's proposal, I can see it is pretty<br>
> much identical to what I've proposed (though his proposal has been around for<br>
> more than a year). Do you have any information as to whether anyone has<br>
> been/is working on implementing it?<br>
<br>
</div>I'm not aware of anyone doing that.  I believe, it was a potential GSoC project<br>
but nobody had the time to mentor it.  See also:<br>
<a href="https://www.torproject.org/getinvolved/volunteer.html.en#httpsImpersonation" target="_blank">https://www.torproject.org/getinvolved/volunteer.html.en#httpsImpersonation</a><br>
<div class="im"><br>
> As for suggestions such as SWEET, FreeWave, etc. - those would require<br>
> changes to the TOR clients (right?), which makes them probably less easy to<br>
> use, unless they are merged into the TOR mainline. Same goes for ScambleSuit,<br>
> since the shared secret much somehow be delivered out-of-band, which is not<br>
> always an easy feat to accomplish.<br>
<br>
</div>Not necessarily.  The idea of obfsproxy is to put circumvention functionality<br>
into a separate program and let Tor only do what it does best: provide<br>
anonymity.  Besides, the circumvention race is a quick one and obfsproxy makes<br>
it possible for us to (semi-)quickly deploy novel circumvention protocols.<br>
Also, because it makes use of Python which is more pleasant for experimental<br>
protocols than C.<br>
<br>
Nevertheless, as you say, many of these protocols require changes to obfsproxy<br>
or completely new frameworks.  Regarding ScrambleSuit's shared secret: some<br>
parts in the Tor world must be changed but we are working on it.  For more<br>
details, please see:<br>
<a href="https://trac.torproject.org/projects/tor/ticket/8979" target="_blank">https://trac.torproject.org/projects/tor/ticket/8979</a><br>
<a href="https://trac.torproject.org/projects/tor/ticket/9013" target="_blank">https://trac.torproject.org/projects/tor/ticket/9013</a><br>
<div class="HOEnZb"><div class="h5"><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>
</div></div></blockquote></div><br></div>