Add HTTPT as a pluggable transport to Tor Browser

The FOCI'20 HTTPT paper was the focus of today's anti-censorship reading group. HTTPT a great candidate for our next pluggable transport. This issue summarises what deployment could look like both for client and server.

HTTPT Client

We could take the existing client implementation and turn it into a new transport for obfs4proxy. In addition, @sergey mentioned that he wants to add Turbo Tunnel to HTTPT.

HTTPT Server

The server side is a bit more complicated. There is a server implementation that relies on a Web server forwarding traffic to it. The implementation is not yet ready to work in the context of Tor though. We have two options:

1. Let a Tor bridge spawn HTTPT, similar to how it spawns obfs4.
   • The easiest way to go down that route would be to add an HTTPT server implementation (in addition to the client implementation, which we need anyway) to obfs4proxy.
   • In addition to HTTPT, we will need a Web server and Web server content. In Section 3.2, the HTTPT paper lists several options.
2. Operate HTTPT independently of a Tor bridge.
   • This has the benefit that one can start an HTTPT proxy without running a Tor bridge.
   • For HTTPT to make it into BridgeDB (or rather rdsys, our re-design), it will have to register itself because there won't be a Tor bridge. We currently don't have a mechanism for that but were planning on implementing one.
   • For now, we could assume that HTTPT operators already have a Web server, and activate HTTPT by simply adding a forward rule to their Web server configuration. In the future, we may want to think about bundling a Web server with HTTPT, so operators that don't have a Web server already can easily spin up a new HTTPT instance.
   • An open question is: what bridge should the HTTPT server connect to? We could set up a centralised and dedicated HTTPT bridge, similar to the one we have for Snowflake.

TODO list

• Add Turbo Tunnel to HTTPT (httpt#2 (moved)).
• Add HTTPT client implementation to obfs4proxy (httpt#3 (moved)).
• Experiment with ways to add synthetic content to Web servers (httpt#4 (moved)).
• Build an API that lets PTs register themselves to rdsys (tpo/anti-censorship/rdsys#4 (closed)).
• Teach the HTTPT server to register itself to rdsys and use a centralised bridge to forward traffic to (httpt#5 (closed)).

Let's use this issue to coordinate deployment and file child issues for more specific tasks. I'm also copying @cohosh, @dcf, @arma, and @sergey.