CGI variable values incorrect on HTTPS sites

[Dan Skaggs]

We are having an issue with our Lucee installation where the https, server_port, and server_port_secure variables in the CGI scope have the wrong value.

Our infrastructure routes requests through a Sophos Firewall/Load balancer to Apache (on CentOS 6) and finally proxied to Tomcat. The server was set up some months ago using the Lucee installer with (I think) mod_cfml 1.0. The SSL certificate is installed on the Sophos, and it is set up to use an HTTPS connection to Apache and pass the host header. Our VHOST file for the site I'm testing with *only* contains an entry for *:443 so there's no chance that Apache is choosing the wrong site config.

The CGI values come across as below:

https: <empty string>

server_port: 80

server_port_secure: 0

One of their techs sent me to this article from the Railo mailing list from last year which sounds like the same issue. I did put the 'RequestHeader set https on' directive into the Apache config and saw the cgi.https value change to "on" so I know we're in the correct config.

https://groups.google.com/forum/#!topic/railo/fXF5PLGrNAg

The legacy code base we're trying to migrate to this new infrastructure runs 150+ sites and uses those CGI variables in all kinds of places. I'm trying to come up with a way to resolve this without having to go digging through hundreds of thousands of lines of code and changing references everywhere.

My only idea right now is to upgrade to the latest Lucee stable (an issue in an of itself b/c of issues with Taffy on another app we need to test), then in the top of the application.cfm (yes I know...not my code) change the value of the cgi variables if cgi.https = 'on' so that the rest of the code functions as expected.

So, that's a long-winded setup to say, doesn't this seem like a bug in Lucee if the request is getting to the correct HTTPS Apache config but Lucee isn't reporting correctly?

Thanks in advance,

Dan

[Terry Whitney]

Typically, if you are using a load balancer you would run all your sites behind in http and the load balancer would do all the hard work of providing the SSL certificate. This way you can have multiple hosts load balancing off a single public ip.

[Dan Skaggs]

Yeah, I don't really like the idea that there are 2 SSL handshake processes going on (one from client > LB and one from LB > Apache), but that's preferable right now to crawling through this 10+ year old spaghetti code base changing things without a way to reliably test everything that's going on. The previous infrastructure used 1 Apache instance as the "load balancer" to several Railo 3 instances so we're trying to adapt to a new infrastructure with as few code changes as possible to limit the amount of ways this thing can go sideways.

There are several things I've found already after not even looking too hard that rely on these CGI values for changing the way the application behaves. Refactoring and testing all that during this migration is less than optimal.

I seriously may have to use the writable CGI scope feature in the latest Lucee stable and "fool" the rest of the app into doing what I want it to do, but that seems like a giant hack.

--
See Lucee at CFCamp Oct 22 & 23 2015 @ Munich Airport, Germany - Get your ticket NOW - http://www.cfcamp.org/
---
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/5c4f92e0-8814-4a9c-8930-ad0aaa678bb9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Terry Whitney]

.

The way SSL works, its not a bug, rather its how the request is being handled. Some items will get mangled if you try to double encrypt them.

Without looking at your configuration, not sure where the error is but typically this is how your setup should look

firewall ---->  IP1   ---> Apache ----> mod_ssl / mod_cfml ----> ip1 of internal CF instance

firewall ---->  IP2   ---> Apache ----> mod_ssl / mod_cfml ----> ip2 of internal CF instance

firewall ---->  IP3   ---> Apache ----> mod_ssl / mod_cfml ----> ip3 of internal CF instance

So on and so forth.

On Tuesday, September 1, 2015 at 9:05:56 AM UTC-4, Dan Skaggs wrote:

[Jordan Michaels]

Hi Dan,

Just saw this.

Have you tried switching from mod_proxy_http to mod_proxy_ajp on your web node? The installer uses mod_proxy_http by default, which may be replacing some of your original HTTP values when it makes the connection from Apache to Tomcat. This means that the fact that you're encrypting both your connections (to the load balancer and to the web node), isn't a factor here, because it's the connection from Apache to Tomcat that is changing your HTTP headers.

Talk with Luke about changing your Apache to Tomcat proxy method from mod_proxy_http to mod_proxy_ajp. He may need to custom compile it for you, but if I'm right, it should retain your original HTTP variables that you're wanting.

Kind regards,
Jordan Michaels

--
See Lucee at CFCamp Oct 22 & 23 2015 @ Munich Airport, Germany - Get your ticket NOW - http://www.cfcamp.org/
---
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/6c41a133-9ca5-4a2b-a611-3d7493d8b3a7%40googlegroups.com.

[Dan Skaggs]

Thanks Jordan...

I just checked and no, it's still using the http proxy. I didn't even think to check that part. I've sent a note to Luke to see what we need to do.

Thanks
Dan

> To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/1034011594.1230.1441132278035.JavaMail.zimbra%40viviotech.net.

[Pete Freitag]

On Tue, Sep 1, 2015 at 10:30 AM, Terry Whitney <twhitn...@gmail.com> wrote:

Typically, if you are using a load balancer you would run all your sites behind with http and the load balancer would do all the hard work of providing the SSL certificate.

Keep in mind that the traffic from your LB to your App server would then be plain text with that approach, which depending on your use case may be acceptable, but for many use case it is not (especially if that traffic is over a public cloud network).

--

Pete Freitag
https://foundeo.com/ - ColdFusion Consulting & Products
http://hackmycf.com - CFML Server Security Scanner

[Terry Whitney]

Not sure of any deployment option in which placing your ssl load balancer on the same side as publicly rotatable hosts would make sense. 

I'm not surprised someone would try it, but the performance would be horrible.

As for the modules, here is a break down of what I have learned over the years.

mod_apj is how AFC is delivered starting with version 10

mod_apj works best when its per server. Per virtual host uses slightly more memory per instance.  Not friendly with multiple mod_ssl implementations.

mod_cfml is what I use for lucee on CentOS 6 & 7, and mod_apj is included with the Centos 7 core install of httpd (apache) 

mod_cfml is fast, and lets you have control per vhost / application container. Its actually set up by default this way and includes application finger printing to help avoid configuration issues as well as add an extra layer or security.

On Tuesday, September 1, 2015 at 9:05:56 AM UTC-4, Dan Skaggs wrote:

[Michael Offner]

Sorry when I miss something, this are just my 2c, the cgi scope is just a proxy for the underlying request object from the servlet engine (tomcat), so what you see is coming from the servlet engine Lucee only forwards the data.

Micha

--

[Dan Skaggs]

Just to follow up and close the loop on this...we inserted the RequestHeader statement previously mentioned and, per Jordan's suggestion, changed the Apache config for that site to use AJP to proxy to Tomcat. As soon as we did that, we started seeing the correct values in CGI.https, CGI.server_port and CGI.server_port_secure.

We're continuing to test right now as this site is being migrated from a previous hosting infrastructure running Railo 3.3 but so far our testing is going well.

Thanks for everyone's comments and suggestions.

Dan

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBxQK8W4j8PX11aE5yzSrvcWCYF_iJbv-LORBAxaR6snHQ%40mail.gmail.com.