1

I have a situation where the main website is a legacy app written in ColdFusion which I've recently migrated from MX 6.1 to 9.0.1. Another part of the website is a blog/forum in PHP5 on WordPress. Now, I'm adding a paid membership feature and integrating with the Chargify V2 API using Ruby & Sinatra. Fun, heh? Anyway, right now I've got the beginnings of things working using mod-proxy to send requests from a certain subdirectory on the main CF site to the Sinatra app. This is working fine over HTTP; Port 80 to Port 9292. But what will happen when I attempt to use HTTPS; Port 443 to Port 9292? I don't currently have a certificate for this host as one has not been necessary in the past, so I'm not sure how to experiment. I just want to be sure that the browser will not complain about the unorthodox arrangement. I'm not actually worried about the form submission being secure because the app is encrypting it w/o SSL. The only reason I want to use SSL is for user confidence. Therefore it's of utmost importance that there are no complaints from the browser that might reduce user confidence (and thus conversions).

Day Davis Waterbury
  • 115
  • 5

1 Answers1

1

Users will have no idea that the connection is not encrypted between the proxy server and the backend server; their connection is only to the proxy. But, I can't blame your users for not trusting the encryption of form data outside of SSL - I wouldn't either!

In any case, you shouldn't deploy an HTTPS-proxied-to-HTTP system in this way unless you're absolutely sure that the traffic between the proxy and the backend is secure. If that broadcast domain is accessible to any users (instead of just servers), for instance, they could easily ARP poison and capture that traffic.

If there's any risk of that happening at all, then use SSL for the communication between the proxy and the backend - not a lot of effort is required to set it up.

To get a test case going, you can just set up a self-signed certificate and start an SSL listener.

Listen 443
<VirtualHost *:443>
    ServerName ssl.example.com
    SSLEngine On
    SSLCertificateFile /path/to/cert.pem
    SSLCertificateKeyFile /path/to/cert.key
    ProxyPass / http://backend:9292/
    ProxyPassReverse / http://backend:9292/
</VirtualHost>
Shane Madden
  • 112,982
  • 12
  • 174
  • 248
  • Many thanks. Port 9292 is only open to traffic from localhost. It's looking for a local IP that is not "localhost" not 127.0.0.1 and not the same as the the public IP. Before someone could spoof the IP, they'd need to know what to spoof. Also, since 9292 is the default port, I'm planning to change that as well. But since you've expressed concern, and you're right that obfuscation alone is not good security, I will look into doing it the right way. Thanks again. – Day Davis Waterbury May 26 '12 at 03:34