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