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:
1. Connection establishment:
+------------------------------+ |CONNECT bridge_ip:443 HTTP/1.0| |User-agent: blablabla | +------------------------------+ | | +----------+ | +----------+ +----------+ | client |----->| proxy |----->| bridge | +----------+ +----------+ | +----------+ | | +------------------------------+ | (Establish a connection) | +------------------------------+
2. 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!
[1]: http://xmpp.org/extensions/xep-0124.html
Best, Chang
Sent from my mobile device. Sorry for the brevity.
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!
Hi Chang,
Thanks for the update. BOSH certainly looks like a promising basis, though of course it makes no attempt at obfuscation or scanning resistance.
I've added this to the design document: https://github.com/sjmurdoch/http-transport/blob/master/design.md
I was thinking about this being a useful basis for you to have for refining your design, so do feel free to fork and change it.
Best wishes, Steven
On 28 Jun 2013, at 16:07, Chang Lan changlan9@gmail.com wrote:
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!
Best, Chang
Sent from my mobile device. Sorry for the brevity. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
-
Chang Lan -
George Kadianakis -
Steven Murdoch