CGI variable values incorrect on HTTPS sites

dev google-group-archive
1

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:
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

2

.

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:

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:
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.

Redirecting to Google Groups

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

3

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----- Original Message -----
From: “Dan Skaggs” <@Dan_Skaggs>
To: “Lucee” lucee@googlegroups.com
Sent: Tuesday, September 1, 2015 6:05:55 AM
Subject: [Lucee] CGI variable values incorrect on HTTPS sites

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:
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

–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/6c41a133-9ca5-4a2b-a611-3d7493d8b3a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

4

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.On Tuesday, September 1, 2015 at 9:05:56 AM UTC-4, Dan Skaggs wrote:

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:
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.

Redirecting to Google Groups

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

5

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> On Sep 1, 2015, at 2:31 PM, Jordan Michaels <@Jordan_Michaels> wrote:

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

----- Original Message -----
From: “Dan Skaggs” <@Dan_Skaggs>
To: “Lucee” lucee@googlegroups.com
Sent: Tuesday, September 1, 2015 6:05:55 AM
Subject: [Lucee] CGI variable values incorrect on HTTPS sites

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:
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.

Redirecting to Google Groups

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

–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/6c41a133-9ca5-4a2b-a611-3d7493d8b3a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/1034011594.1230.1441132278035.JavaMail.zimbra%40viviotech.net.
For more options, visit https://groups.google.com/d/optout.

6

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:

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:
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.

Redirecting to Google Groups

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

7

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> On Sep 3, 2015, at 2:57 AM, Michael Offner <@Michael_Offner> wrote:

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

Am Dienstag, 1. September 2015 schrieb 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:
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.

Redirecting to Google Groups 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

–
See Lucee at CFCamp Oct 22 & 23 2015 @ Munich Airport, Germany - Get your ticket NOW - http://www.cfcamp.org/ 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+unsubscribe@googlegroups.com <javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com <javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/6c41a133-9ca5-4a2b-a611-3d7493d8b3a7%40googlegroups.com https://groups.google.com/d/msgid/lucee/6c41a133-9ca5-4a2b-a611-3d7493d8b3a7%40googlegroups.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.

–
See Lucee at CFCamp Oct 22 & 23 2015 @ Munich Airport, Germany - Get your ticket NOW - http://www.cfcamp.org/ 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+unsubscribe@googlegroups.com mailto:lucee+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com mailto:lucee@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG%2BEEBxQK8W4j8PX11aE5yzSrvcWCYF_iJbv-LORBAxaR6snHQ%40mail.gmail.com https://groups.google.com/d/msgid/lucee/CAG%2BEEBxQK8W4j8PX11aE5yzSrvcWCYF_iJbv-LORBAxaR6snHQ%40mail.gmail.com?utm_medium=email&utm_source=footer.
For more options, visit https://groups.google.com/d/optout https://groups.google.com/d/optout.

8

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.

MichaAm Dienstag, 1. September 2015 schrieb 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:
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.

Redirecting to Google Groups

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

–
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+unsubscribe@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee%2Bunsubscribe@googlegroups.com’);>.
To post to this group, send email to lucee@googlegroups.com
<javascript:_e(%7B%7D,‘cvml’,‘lucee@googlegroups.com’);>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/6c41a133-9ca5-4a2b-a611-3d7493d8b3a7%40googlegroups.com
https://groups.google.com/d/msgid/lucee/6c41a133-9ca5-4a2b-a611-3d7493d8b3a7%40googlegroups.com?utm_medium=email&utm_source=footer
.
For more options, visit https://groups.google.com/d/optout.