I met today with some developers of Lantern (https://getlantern.org/, https://github.com/getlantern/lantern). Lantern acts as an HTTP proxy and proxies your traffic through trusted friends. We found that we had the pieces necessary to make Lantern a pluggable transport of Tor; that is, use Lantern as a transport for Tor traffic where Tor is blocked but Lantern is not. Here's what we did to make it work.
Lantern is an HTTP proxy. As luck would have it, I have lately been working on a transport that encodes data in HTTP requests (https://lists.torproject.org/pipermail/tor-dev/2014-January/006159.html). meek was designed for a completely different purpose--tunneling traffic through App Engine--but it turned out to be almost perfect for the Lantern case, too. The only thing it was missing was support for an upstream HTTP proxy. We used the attached patch to add proxy support and hardcode Lantern's proxy port of 8787.
meek normally connects to App Engine, and uses a TLS trick to make it look like it is going to www.google.com. The meek-client program connects App Engine, and then App Engine forwards traffic to the bridge. The configuration looks like this: ClientTransportPlugin meek exec meek-client --url=https://meek-reflect.appspot.com/ --front=www.google.com With Lantern it's a bit different. We don't need to do the TLS fronting trick because we use Lantern as an opaque HTTP-carrying transport. Instead of going through App Engine, we tell meek-client to make requests directly to the Tor bridge (where "directly" means "directly through the Lantern proxy"). ClientTransportPlugin meek exec meek-client --url=http://tor1.bamsoftware.com:7002/
And that's all. We downloaded one of the experimental meek bundles from https://people.torproject.org/~dcf/pt-bundle/3.5.2.1-meek-1/, copied in the patched meek-client binary, and made the above change to the ClientTransportPlugin line in torrc-defaults. With Lantern already running and configured on the same machine, we started tor and it bootstrapped.
I'll take the proxy patch and modify it so that the proxy address is not hardcoded, so that you can configure it from the command line. It could also be useful for users who need pluggable transports but are stuck behind an HTTP proxy.
Special thanks to Ox from Lantern who pair-programmed this with me.
David Fifield
On Sat, Mar 01, 2014 at 10:27:05PM -0800, David Fifield wrote:
Lantern is an HTTP proxy. As luck would have it, I have lately been working on a transport that encodes data in HTTP requests (https://lists.torproject.org/pipermail/tor-dev/2014-January/006159.html). meek was designed for a completely different purpose--tunneling traffic through App Engine--but it turned out to be almost perfect for the Lantern case, too. The only thing it was missing was support for an upstream HTTP proxy. We used the attached patch to add proxy support and hardcode Lantern's proxy port of 8787.
I made some commits that make it possible to control the proxy through the command line or with SOCKS args. So for example, Bridge meek 0.0.2.0:1 ClientTransportPlugin meek exec ./meek-client --url=http://tor1.bamsoftware.com:7002/ --http-proxy=http://127.0.0.1:8787/ or if you have a newer tor supporting SOCKS args, you can use Bridge meek 0.0.2.0:1 url=http://tor1.bamsoftware.com:7002/ http-proxy=http://127.0.0.1:8787/ ClientTransportPlugin meek exec ./meek-client
David Fifield
-
David Fifield