Total Pageviews

Sunday, 12 June 2016

HTTPTunnel

Tunneling (through SOCKS) using only http requests.
Proxy server that uses only HTTP request for the data transferring.
On applications perspective, HTTP Tunnel tries to provide a general purpose communication layer using only HTTP request. On developers perspective, it is a research on how HTTP may be used for streaming general purpose data (both upload and download).
Right now it is fully functional but a bit slow for highly interactive applications (see "Known bugs and Limitations"). For web browsing, it practically does not affect the user experience.

Installing

Three tiers are involved in the HTTP Tunnel: 1. SOCKS5 server. Will be run locally on your machine. It adapts the communication to the HTTP protocol. 2. CGI capable HTTP web server. Will forward the data to the connection pool. 3. Connection pool daemon. Will establish the actual connection with destination.
All coding was done using Python 3.3, so both your machine and web server must have it installed.
The SOCKS5 server will run locally on your machine. While the CGI script and connection pool must be installed on a server.

Remote machine (the web server)

  1. Run run_daemon.py, it will open the connection pool daemon on the default port.
  2. Put the source code in your web server's appropriate folder. You will need the URL for the index.py, which will receive the HTTP requests and forward it to the connection pool.

Local machine

  1. Just run run_client.py url port. Where url is the URL to the index.py in your web server, and port is which port the SOCKS will listen to.

How it works

HTTP Tunnel creates a SOCKS5 server on the local machine. When a new connection is issued to the SOCKS5 server it will redirect the data to an external server through HTTP requests. The CGI script that receives HTTP requests will just redirect data to a connection pool daemon that keeps the real connection (the connection with the actual destination) alive between requests. This daemon is necessary because the end-to-end communication comprises lot of small HTTP Requests.
The communication goes through the following path:
  • Alice
    • Application protocol over SOCKS5 Protocol
  • SOCKS5 server
    • Internal protocol over pure HTTP
  • HTTP Server
    • Internal low level protocol
  • Connections pool
    • Application protocol
  • Bob
Note that the interface of the local machine with the external world is at "Internal protocol over pure HTTP", this means that for external observers you are just doing HTTP requests.

Features

HTTP Tunnel works with HTTP and HTTPS (secure HTTP), any application that works with SOCKS5 shall work fine with HTTP Tunnel.

Known bugs and Limitations

Right now, HTTP Tunnel is to slow for interactive applications. Tests with SSH showed that the a few seconds are needed to feedback key presses.
This happens because data uploading through HTTP Tunnel is unoptimized. While it is easy to stream data from HTTP (see Chunked transfer encoding), it is hard to stream data to HTTP, because the client must send the length of uploaded content in the request headers.
Also with SSH, if the remote burst information (tested with strings /dev/urandom), the connection will be lost within a few minutes. The cause of this behavior is still unknown.
And finally, the thread handling on the SOCKS server is a bit poor and apparently some threads are alive even after their respective connections were closed.

Future Work

  • Speed and latency optimization (which is the major issue right now)
  • Figure out an way to stream data through HTTP
  • Code refactor
  • Implement reverse proxy (opening a port on the remote server that will redirect to a local server)
  • Fully implement SOCKS5 server and improve its error reporting.
  • Modularization on the protocols. SOCKS5 should become just a wrapper for the actual HTTP protocol, and the HTTP protocol may be used directly. I.e. create something like a socket but using HTTP as communication layer。

from https://github.com/Andrepuel/HttpTunnel
-------

Bidirectional data stream tunnelled in HTTP requests.

About

httptunnel creates a bidirectional virtual data path tunnelled in HTTP
requests. The requests can be sent via an HTTP proxy if so desired.
This can be useful for users behind restrictive firewalls. If WWW
access is allowed through an HTTP proxy, it's possible to use
httptunnel and, say, telnet or PPP to connect to a computer outside
the firewall.
If you still don't understand what this is all about, maybe you
can find some useful information in the FAQ file.
This program is mostly intended for technically-oriented users.
They should know what to do.

Install

Read INSTALL for instructions on how to build a released version.
If you build the development repository, run ./autogen.sh first.

License

httptunnel is free software. See COPYING for terms and conditions.
If you like it, I would appreciate if you sent a post card to:
Lars Brinkhoff
Bokskogsbacken 66 422 56 Goteborg
Sweden
Information and/or latest release should be available from these places:
I take no responsibility for what you do with this software. It has
the potential to do dangerous things, like disabling the protection
you system administrator has set up for the local network. Read the
DISCLAIMER file.

Usage & Documentation

There are two programs: hts and htc. hts is the httptunnel server
and htc is the client. hts should be installed on a computer outside
the HTTP proxy, and htc should be installed on your local computer.
Documentation about how to use the programs should be searched in this
order:
  1. source code
  2. --help output
  3. FAQ
  4. README
Having said that, here are some examples:
  • start httptunnel server:
  • At host REMOTE, start hts like this:
    hts -F localhost:23 8888 (set up httptunnel server to listen on port 8888 and forward to localhost:23)
  • start httptunnel client:
    • At host LOCAL, start htc like this:
      htc -F 2323 -P PROXY_ADDRESS:8000 REMOTE_IP:8888 (set up httptunnel client to forward localhost:2323 to REMOTE_IP:8888 via a local proxy at PROXY_ADDRESS:8000)
  • or, if using a buffering HTTP proxy:
    htc -F 2323 -P PROXY_ADDRESS:8000 -B 48K REMOTE_IP:8888
  • Now you can do this at host LOCAL:
    telnet localhost 2323 (telnet in to REMOTE_IP:8888 via your httptunnel you just configured above on port localhost:2323)
    ...and you will hopefully get a login prompt from host REMOTE_IP.
  • Debugging:
  • For debug output, add -Dn to the end of a command, where n is the level of debug output you'd like to see, with 0 meaning no debug messages at all, and 5 being the highest level (verbose).
  • ex: htc -F 10001 -P PROXY_ADDRESS:8000 REMOTE_IP:8888 -D5 will show verbose debug output (level 5 debugging) while setting up an httptunnel client to forward localhost:10001 to REMOTE_IP:8888 via a local proxy at PROXY_ADDRESS:8000

External help, examples, & links

from https://github.com/larsbrinkhoff/httptunnel
---------

相关帖子:briteming.blogspot.com/2016/03/http-tunnel.html