Please, take a look at the following diagram.
How should this work?
When a remote requests http:// myhost.com:8080/* , the request should be forwarded to the http server that listens on port 8008 of the loopback interface. This is the easy part.
When a remote user requests http:// myhost.com:8080/specialurl ...
The program acting as an application level gateway should be able to upgrade the connection to an encrypted session (without changing ports)
After establishing an encrypted session with the remote browser, it should forward the request to the C program that listens on port 8000 of the loopback interface
My questions are:
- Have you ever deployed a solution like this on a production environment? If you have...
- What product did you use to act as an application gateway?
- Could you provide a configuration example?
- I do not have control over the firewall, and the only port through which i can get external traffic into the internal server is 8080. The port number is irrelevant, the thing is that there is only one port open at the firewall level that forwards incoming traffic to the internal server.
- Internal server must be running Linux (currently it is running Debian Lenny)
- Remote users should need nothing more than a current web browser and an Internet connection to access this server. This means that reverse port forwarding through SSH is not an option here.
- I need a product that has been tested in production and that can be readily deployed. I'm not looking to develop my own application gateway (if that were the case, i guess i would be asking this question at Stack Overflow instead of asking it at Server Fault).
- I'd like to avoid putting Apache as an application gateway (although i'm willing to do that if it's the only possible choice)
- If possible, the application gateway should be a mature, open source software product.
Products tried so far as application gateways (without success)
- RFC2817 ( ... explains how to use the Upgrade mechanism in HTTP/1.1 to initiate Transport Layer Security (TLS) over an existing TCP connection. This allows unsecured and secured HTTP traffic to share the same well known port ... )
- RFC2818 ( ... describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL (the predecessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port ... )