Chang Lan changlan9@gmail.com writes:
Hi there,
During the first two weeks of my GSoC project, I have implemented a HTTP CONNECT-based pluggable transport. In short, I use HTTP CONNECT semantics to establish a secure channel between the client and the bridge. Specifically, this is the scenario:
Connection establishment:
+------------------------------+ |CONNECT bridge_ip:443 HTTP/1.0| |User-agent: blablabla | +------------------------------+ | |
+----------+ | +----------+ +----------+ | client |----->| proxy |----->| bridge | +----------+ +----------+ | +----------+ | | +------------------------------+ | (Establish a connection) | +------------------------------+
Data relay
+------------------------------+ | (Encrypted Payload) | +------------------------------+ | |
+----------+ | +----------+ +----------+ | client |<----->| proxy |<----->| bridge | +----------+ +----------+ | +----------+ | | +------------------------------+ | (Encrypted Payload) | +------------------------------+
I hope the diagrams above are self-explanatory. It is only my initial attempt to get familiar with HTTP protocol. Once I make sure it is working correctly under squid proxy I will upload it to the repository.
The use of CONNECT method is restricted in many networks, so it is better to implement the HTTP transport using the usual HTTP methods as POST, GET, etc. In the next stage, I plan to implement a new HTTP transport based on BOSH[1]. There are many issues to care about (in order of priority):
- bi-directional data transfer over HTTP
- proxy cache
- HTTP request/response encoding
- encryption
- scanning resistance
Have a nice weekend!
Hi Chang,
do you have a specification document for the pluggable transport you are implementing? Coding stuff without a specification is not the right way to do this, and it also makes it much harder for us to evaluate whether your pluggable transport is a good idea.
For example, which ideas from https://github.com/sjmurdoch/http-transport/blob/master/design.md will you end up using?
Thanks!