[tor-dev] Idea regarding active probing and follow-up of SSL connections to TOR bridges

[Lag Inimaineb]

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 at 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 at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130727/ca2f8cb8/attachment.html>