10

Please, take a look at the following diagram.

alt text

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:

  1. Have you ever deployed a solution like this on a production environment? If you have...
  2. What product did you use to act as an application gateway?
  3. Could you provide a configuration example?

Hard restrictions:

  • 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).

Soft restrictions:

  • 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)

  • nginx
  • lighttpd
  • pound

Relevant RFCs

  • 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 ... )
Joseph Quinsey
  • 222
  • 6
  • 17
alemartini
  • 1,023
  • 1
  • 6
  • 14
  • "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)" ...how is that possible on the client side? Will a client browser support running SSL through a url that doesn't contain https? – Adam Brand Aug 01 '09 at 20:17
  • Hi Adam, and thanks for leaving your comment. After requesting http://myhost.com:8080/specialurl, the browser should be redirected to https://myhost.com:8080/specialurl. I'm not sure about other browsers, but recent versions of Opera and Firefox seem to support this without problems. – alemartini Aug 01 '09 at 21:36

2 Answers2

1

One port to rule them all, shows someone has atleast implemented it in the java world.

Have you ever deployed such a solution in a production environment?

I have not -- nor would I ever recommend it be done. As a consultant I try to encourage my clients to use standardized and proven technologies. No system seems to properly implement those RFC's except for edge cases -- and that would not be something I would want to suggest or support.

SirStan
  • 2,373
  • 15
  • 19
  • Hi Stan, and thak you for the feedback. I wasn't aware of Grizzly, and unfortunately i am not familiar with Java. Have you ever deployed such a solution in a production environment? It would be great if you could share an example showing how to do it. Thanks again, Alex. – alemartini Jul 31 '09 at 02:14
  • Ok, thanks for editing your answer and adding more information. As you can see, i've now narrowed my question, stating more clearly that i'm looking for a mature product. Let's see if someone comes up with a good answer to this one. It's hard to believe that Apache is the one and only application on the Linux world that supports RFC2817. But if that's the case, or if no one else has real world experience deploying something like this with another product, i think i'll have no choice except trying to solve this with Apache. – alemartini Aug 01 '09 at 04:50
0

Apache won't help you here. It can only listen for HTTP or HTTPS connections (not both) on any given port.

As far as I know, there is no "mature product" which implements this functionality. Get your network administrator to punch you another hole in the firewall, or set up a VPN or SSH tunnel to an external endpoint where you can set up multiple listening ports.