Click here to Skip to main content
65,938 articles
CodeProject is changing. Read more.
Articles
(untagged)

HTTP Tunneling

0.00/5 (No votes)
14 Jun 2000 18  
This article describes how to open arbitrary TCP connections through proxy servers

Introduction

The application discussed in this article provides the ability to make TCP connections through a proxy server. Often, computers are behind firewalls that deny many connections. But HTTP connection is usually allowed and is made through a proxy server. This article will show how arbitrary TCP connections can be made using HTTP protocol and the proxy server.

Approach

When an HTTP connection is made through a proxy server, the client (usually the browser) sends the request to the proxy. The proxy opens the connection to the destination, sends the request, receives the response and sends it back to the client. The HTTP protocol specifies a request method called CONNECT. The CONNECT method can be used by the client to inform the proxy server that a connection to some host on some port is required. The proxy server, if it allows such connections, tries to connect to the destination address specified in the request header. If the operation fails, it sends back to the client a negative HTTP response and closes the connection. If the operation succeeded, then it sends back an HTTP positive response and the connection is consider established. After that, the proxy does not care what data is transferred between client requesting the connection and the destination. It just forwards data in both ways acting as a tunnel.

About the Protocol

We are interested in CONNECT method from the HTTP protocol. After the application opens a connection with the proxy server, it must send the connect request in the form of an HTTP request:

CONNECT <destination_address>:<destination_port> <http_version><CR><LF>
<header_line><CR><LF>
<header_line><CR><LF>
...
<header_line><CR><LF>
<CR><LF>

The proxy server processes the request and tries to make a connection to <destionation_address>:<destination_port>.

The proxy server sends back an HTTP response in the form:

<http_version> <code> <message><CR><LF>
<header_line><CR><LF>
<header_line><CR><LF>
...
<header_line><CR><LF>
<CR><LF>

If it is a positive response (code=200), then after the empty line the proxy begins to acts as a tunnel and forwards data. If it is a negative response (code!=200), then connection is closed after the empty line.

The HTTPTunneling Application

The application acts as specified in a configuration file. An entry in the configuration file looks like this:

<Source port> <Destination address> <Destination port> <Proxy address> <Proxy port>

If the application is running and an entry in the configuration files changes, the application automatically updates itself.

For every entry in the configuration file, the application creates a port listener. This is a thread that opens a socket on <Source port> and waits for connection. When a request arrives on that port, it tries to open a tunnel to the <Destination address>:< port>. If the <Proxy address> and <Proxy port> are missing, a direct connection is made. If the field is present, it opens a connection to the proxy and sends a CONNECT request using the method specified above. The tunnel construction is made in a separate thread to let the port listener to accept immediately new connections. After the connection is established, a tunnel object is constructed based on the opened sockets, sockets are marked as non-blocking and the object is passed to manager object. The thread that has created the tunnel is destroyed. Data transfer is made on a single thread. When one of the ends closes the connection, the tunnel closes the other and the tunnel is marked as inactive. The manager finds the tunnel inactive and removes it from the list of active tunnels.

By default, the application generates log information in HTTPTunneling.log file. This file can be consulted to find wrong application behaviour.

Known Problems

  • If no data transfer is made, the proxy could close the connection, even though neither the initiator nor the destination has closed the connection.
  • Proxy authorization may be required. This can be easily solved including in the HTTP request the Proxy-Authorization field.

History

  • 15th June, 2000: Initial post

License

This article has no explicit license attached to it, but may contain usage terms in the article text or the download files themselves. If in doubt, please contact the author via the discussion board below. A list of licenses authors might use can be found here.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here