[guardian-dev] Fwd: Re: [tor-dev] Obfsproxy client for Android

Nathan of Guardian nathan at guardianproject.info
Fri Feb 10 08:16:42 EST 2012


For those not aware, Iran has begun seriously filtering all SSL/TLS
traffic attempting to leave the country, even on port 443. This means
services such as Tor are being mostly blocked. You can get all the
details here:
https://lists.torproject.org/pipermail/tor-talk/2012-February/023070.html

Fortunately, there is a solution, but if we want Orbot to support it, it
means both a new settings feature, as well as porting of a new binary.
Info on what needs to be done is below. I will be working on this over
the next few days. All are welcome to pitch in.

-------- Original Message --------
Subject: Re: [tor-dev] Obfsproxy client for Android
Date: Fri, 10 Feb 2012 08:11:04 -0500
From: Roger Dingledine <arma at mit.edu>
Reply-To: tor-dev at lists.torproject.org
To: tor-dev at lists.torproject.org

On Fri, Feb 10, 2012 at 07:56:04AM -0500, Nathan Freitas wrote:
> Thoughts on attempting to port and ship Obfsproxy client functionality
> to Android?
> 
> We have a good number of Iranian users it seems, and I think we can pull
> it off in a few days, if it isn't insanely complex.
> 
> Where should we begin? Any details on exactly what was done for the new TBB?

Step one, build obfsproxy for Android. I expect your biggest problem
will be libevent2 since you won't have any packages for it. See
https://trac.torproject.org/projects/tor/ticket/5009#comment:17
for some ugly hacks.

Step two, figure out what obfs2 addresses you want your people to use.
In the current testing bundle we're simply hard-coding two (one on moria,
one that marlowe runs). Tomorrow I hope to put out a bundle with more
like 8 or 10, to load balance in case it becomes popular.

Step three, add those obfsproxy bridges and this line to the torrc:

Bridge obfs2 128.31.0.34:1051
ClientTransportPlugin obfs2 exec /path/to/obfsproxy --managed

Now your clients will be good to go. Except every client will launch
obfsproxy by default whether they need it or no, and they'll all go
through that obfsproxy bridge. So you'll want this to be a separate
alternate bundle that people only install when they want it.

Step four, you could change your gui to let people configure new obfs2
bridges that they run across. There's a bug in Vidalia where it tries to
validate your bridge lines, which backfired now that the bridge lines
have become more complex; perhaps Orbot was more future-thinking and
never bothered validating them. :)

Maybe you want to make your interface only add the ClientTransportPlugin
line to the torrc file if they add an obfs2 bridge? Eventually Tor will
be smarter about that.

Oh, and lastly, there's a crash bug in obfsproxy that we're working on
now. Maybe more behind it. This is not what you would call a methodical
planned rollout. :)

--Roger

_______________________________________________


More information about the Guardian-dev mailing list