[tor-dev] Building better pluggable transports - GSoC 2013 project

[David Fifield]

On Tue, Jun 11, 2013 at 05:46:49PM +0100, Steven Murdoch wrote:
> On 11 Jun 2013, at 12:49, Steven Murdoch <[1]steven.murdoch at cl.cam.ac.uk>
> wrote:
> 
>     There certainly are quite a few open questions, so it would be good to
>     start planning early. Implementing HTTP is a deceptively difficult
>     project. 
> 
> I've started a design document https://github.com/sjmurdoch/http-transport/
> blob/master/design.md which is very much a work-in-progress but I'm interested
> in comments.

Here are some ideas on a few things that I've been thinking about
recently, mostly taken from https://www.bamsoftware.com/papers/oss.pdf.
That's an HTTP-based transport, though one with different goals: It's
meant to evade IP-based blocking and not DPI. (The paper does have a
section at the end about mitigations against DPI.)

> Bi-directional data
> Tor requires that communication exchanges be initiated either by the
> bridge client or bridge server. In contrast HTTP clients initiate all
> communications. There are a few ways to avoid this problem:
> * The client periodically polls the server to check if any data is
>   available
> * The client keeps a long-running Comet TCP connection, on which the
>   server can send responses
> * The client and server both act as HTTP clients and HTTP servers, so
>   can each send data when they wish

Making the client an HTTP server has the same NAT problems that flash
proxy has. The OSS model has the worst of both worlds: the client has to
be an HTTP server and also has to poll. But we implemented polling and
it was usable.

> Proxy busting
> Proxies will, under certain conditions, not send a request they
> receive to the destination server, but instead serve whatever the
> proxy thinks is the correct response. The HTTP specification dictates
> a proxy's behaviour but some proxy servers may deviate from the
> requirements. The pluggable transport will therefore need to either
> prevent the proxy from caching responses or detect cached data and
> trigger a re-transmission. It may be unusual behaviour for a HTTP
> client to always send unique requests, so it perhaps should
> occasionally send dummy requests which are the same as before and so
> would be cached.

To inhibit caching we added a random number to every request. However
that's a good point about not having all requests be unique.

> Client to server (requests)
> Cookies
> Short and usually do not change, so possibly not a good choice
> HTTP POST file uploads
> Quite unusual, but permit large uploads

Another avenue is URLs--they are sometime kilobytes long (and clients
and servers support much longer than that), and often contain opaque
binary data.

David