About eGURU
eGURU Process
Operational Details
Participants
Project Ideas
Scholarships
FAQs
The Proposal Details
HTTP Tunnel for TCP connections
Networking
Every medium/big organization deploys firewall to secure internal LAN/WAN network. Constraints placed by a firewall depend on needs of the organization. Some of them may be very restrictive such that only allowable traffic is HTTP. In some situations, there is a need to bypass these constraints, for example, broadcasting lectures videos using RTSP protocol which uses 554 as default port. There are two ways to handle this situation; either create a hole in firewall i.e. open 554 and other related ports, or tunnel RTSP by wrapping it into HTTP which is less risk prone. The theme of this project is to implement tunneling for an arbitrary TCP socket connection over HTTP. The basic idea is to run an instance of the HTTP Tunnel application locally in 'client' mode, which then connects out to another instance that running at the remote end of the tunnel in 'server' mode. Then connecting to the local client end of the tunnel with the application whose traffic is to tunneled, and all communications are then wrapped in HTTP. The tunnel may also go via a HTTP proxy, either explicitly or transparently. Point to be noted here is, this is not a compromise to security, since the main goal of firewall is to secure internal network from outsiders, not filtering access from internal network to outside world.
1.An Http Tunnel Session consists of both Server and Client side component. 2.At client side, HTTP Tunnel instance will listen on a socket. Any incoming traffic is wrapped in HTTP header and transmitted to server end. 3.Any traffic coming back from the server is unwrapped at client side and is sent back to client application. 4.At Server side, HTTP Tunnel Instance will listen for connection from HTTP Tunnel Client. It then strips off the HTTP Headers attached to the message, forwards it out to final destination. 5.Any traffic coming back from final destination is again wrapped in HTTP and then sent down to the client.
1.RFC 3093, st April 2001, http://www.faqs.org/rfcs/rfc3093.html. 2.RFC 2775, February, 2000, http://www.faqs.org/rfcs/rfc2775.html. 3.Computer Networks, Andrew S. Tenenbaum. 3rd Ed., Prentice Hall India.