[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev