[tor-dev] HOWTO use Lantern as a pluggable transport

[David Fifield <david@xxxxxxxxxxxxxxx>]

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

commit bd54bdd4b8d0ac66834fa4897cbea97eac0df120
Author: David Fifield <david@xxxxxxxxxxxxxxx>
Date:   Sat Mar 1 15:29:46 2014 -0800

    Use fixed HTTP proxy http://127.0.0.1:8787/.

diff --git a/meek-client/meek-client.go b/meek-client/meek-client.go
index 6ed9289..872e23f 100644
--- a/meek-client/meek-client.go
+++ b/meek-client/meek-client.go
@@ -36,6 +36,14 @@ var globalURL string
 var handlerChan = make(chan int)
 
 func roundTrip(buf []byte, u, host, sessionId string) (*http.Response, error) {
+	proxyURL, err := url.Parse("http://127.0.0.1:8787";)
+	if err != nil {
+		return nil, err
+	}
+	proxyFunc := http.ProxyURL(proxyURL)
+	tr := &http.Transport{
+		Proxy: proxyFunc,
+	}
 	req, err := http.NewRequest("POST", u, bytes.NewReader(buf))
 	if err != nil {
 		return nil, err
@@ -45,7 +53,7 @@ func roundTrip(buf []byte, u, host, sessionId string) (*http.Response, error) {
 	}
 	req.Header.Set("Content-Type", "application/octet-stream")
 	req.Header.Set("X-Session-Id", sessionId)
-	return http.DefaultTransport.RoundTrip(req)
+	return tr.RoundTrip(req)
 }
 
 func sendRecv(buf []byte, conn net.Conn, u, host, sessionId string) (int64, error) {

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