2

My company is working with a legacy program that listens on port 80. Were trying to meet security requirements by placing an NGINX in front of it to support HTTPS requests that will proxy to the (fire walled) http port.

Our current problem is that the legacy program also has hard coded URLS which point to http port 80. I want to place a redirect on port 80 that will catch these http requests and redirect them to https, but I can't do that as long as the legacy program is bound to port 80.

I can't reconfigure the legacy program's default bind port. Is there a way within centos to force the program to bind to another port when it requests port 80 to bind to?

I'm running on centos 6.9 (like I said, legacy systems).

  • Any reason you can't run Nginx on another server/VM? – garethTheRed Oct 27 '17 at 14:01
  • @garethTheRed just that it would have to be a physical server and we don't want to provide one for that. Plus I think that may technically violate our company security requirements (yes I know it's just as secure, but who said company policies had to make sense?) – dsollen Oct 27 '17 at 14:18
  • I assume your legacy program will also bind to all IPs, or else put the IP into the shipped text just like the port? httpd can run the output from the backend through arbitrary external programs (like sed in this case), maybe nginx has ways of doing that, too? – Ulrich Schwarz Oct 27 '17 at 14:43
  • 2
    could you use some LD_PRELOAD code to make the unknown program listen somewhere else? – thrig Oct 27 '17 at 17:01
  • LD_PRELOAD is the approach I would suggest as well, though I haven't seen a library for doing this before (probably because very few applications, even legacy ones, are stupid enough to hardcode use of a registered port). – Austin Hemmelgarn Oct 27 '17 at 18:37
2

You have a client program on machine A that makes HTTP requests to machine B on port 80. And you have a server program on machine B that listens to HTTP requests on port 80.

If A = B then HTTPS is pointless since the packets between the client and the server never go out onto the network. Hence the only useful case is A ≠ B.

Run an HTTP-to-HTTPS proxy on A and an HTTPS-to-HTTP proxy on B. The proxy on A listens on port 80 and sends requests to B on port 443 (or some other port if you prefer). The proxy on B listens to requests on port 443 (or whichever port you prefered) and sends local requests to port 80. There is no clash between ports.

If there is only one instance of A and B, then an SSH tunnel would be less work to set up than two proxies.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.