[tor-dev] (meek|flashproxy)+(obfs3|fte|scramblesuit|...)

[Kevin P Dyer]

On Sat, Jul 26, 2014 at 5:30 PM, David Fifield <david at bamsoftware.com>
wrote:

> On Sat, Jul 26, 2014 at 03:08:38PM +0100, Kevin P Dyer wrote:
> > Are there any roadblocks that prevent us from doing the following?
> >
> > 1. Remove the hard-coded bridge_prefs.js in the TBB.
> > 2. Set meek as the default pluggable transport in the TBB.
> > 3. Use meek to acquire an up-to-date bridge_prefs.js from, say,
> > torproject.org.
> > 4. Use the information from the acquired bridge_prefs.js to connect to
> Tor as
> > normal.
>
> Flash proxy does something similar when it starts up and does
> rendezvous. The helper program flashproxy-reg-appspot uses the meek
> domain fronting trick (but simpler) to find out its own IP and send it
> to the facilitator. You wouldn't actually need to fire up meek; you
> could just front an HTTPS GET request for the document you need.
>
>
> https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/doc/flashproxy-reg-appspot.1.txt
>
> https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/flashproxy-reg-appspot
>
> I don't know that you'd want to rely on it entirely--meek over App
> Engine doesn't work in China and we haven't deployed any other backends
> yet.


Is App Engine blocked in China?


> Nothing is ever going to be as reliable as a file you already have
> on disk.
>

We could have a file on disk as a fallback option, right?


> I supose this is because you want to make FTE bridges dynamic?
>

Exactly.

-Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140726/588bae7d/attachment.html>