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@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