You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by "Clinton J. Campbell" <cl...@gmail.com> on 2012/07/01 09:40:07 UTC
Re: [users@httpd] Apache modifies URL when offloading SSL
Thanks for the tip Daniel. I ran some more tests while monitoring httpd logs followed by a similar set of tests monitoring the Squid logs with debugging turned on. What I've found is that the connection is initially handled correctly until credentials are posted. At this point, httpd sends an HTTP 303 pointing to the modified URI.
- From browser to squid, the connection is https. The URI in the initial HTTP request is https://www.mydomain.com/administrator.
- From squid to httpd, the connection is http. The URI passed in the HTTP request is still https://www.mydomain.com/administrator/index.php.
- Httpd responds correctly to the request returning the login page. Squid passes the result back to the browser.
- User enters credentials, browser POST to squid. Squid reviews the request, forwards to httpd.
- Httpd replies with HTTP 303, Location: http://www.mydomain.com/administrator/index.php.
- Squid forwards reply to browser, which now connects to squid via http. Connection fails per policy.
I know that this is not an unusual combo, fronting an unencrypted httpd with a proxy accepting connections over https, and the server seems to handle receiving https URI's within headers for GET requests. So I guess I'm still curious whether there is a way to configure httpd to prevent the redirection to http on the POST?
There's one remaining twist in the logs, that also makes me wonder if the problem is coming from Joomla. I ran a scenario lifting the restriction to https and I connected unencrypted to the server. After the POST, the server responds in the same fashion, with an HTTP 303. Is this a standard pattern for httpd with POST requests or is it something that is likely being triggered by the application?
Appreciate the help!
Clinton
On Friday, June 29, 2012 at 9:51 AM, Daniel Ruggeri wrote:
> On 6/29/2012 11:43 AM, Clinton J. Campbell wrote:
> > I'm trying to configure the logs so that I can confirm whether this is generated by Apache or not. Any tips?
>
>
>
> mod_dumpio is the place to be for debugging this kind of stuff. All
> input and output will get logged to show you exactly what httpd is
> reading and writing.
>
> --
> Daniel Ruggeri
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org (mailto:users-unsubscribe@httpd.apache.org)
> For additional commands, e-mail: users-help@httpd.apache.org (mailto:users-help@httpd.apache.org)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Apache modifies URL when offloading SSL
Posted by Igor Cicimov <ic...@gmail.com>.
On Mon, Jul 2, 2012 at 9:01 AM, Clinton J. Campbell <
clinton.campbell@gmail.com> wrote:
> Thanks Daniel (and others) for the help along the way. I've landed on
> pretty much the same conclusion as I've continued researching. The
> additional insight about the redirects helped me craft my searches more
> specifically. I figure I ought to share some of my conclusions for anybody
> who might stumble upon this thread in their own searches later.
>
> I only mentioned one of the scenarios giving me trouble in detail, but
> there are actually three distinct problems now that I know the redirects
> are originating at the application level.
>
> Joomla Administration -- It looks like my best options will be #1 from
> Daniel's reply (adjust application behavior) or #3 (use backend SSL
> connection to trick the application). Option #3 will require additional
> virtual hosts and the challenge will be ensuring the proxy directs the
> traffic properly between the encrypted and unencrypted instances. If I
> happen to send unencrypted traffic to the encrypted backend, I'm afraid I
> might end up with similar redirects causing undesirable behavior. The
> workload on these servers is relatively low, so I'm leaning toward #3 since
> it will minimize the administrative burden going forward.
>
> Joomla Plugins (extplorer) -- I'm hopeful that option #3 will resolve my
> issues for Joomla plugins, though I may need to look more deeply into
> option #1 here as well.
>
> WebDAV -- I believe I'm limited to option #2 (rewrite the response at the
> proxy) and option #3. Again I'm leaning toward #3 since it is the easiest
> administratively. If the traffic load increases down the road, I may
> reconsider.
>
> Finally, here are some references I intend to consult as I go forward:
>
> http://stackoverflow.com/questions/1110710/webdav-behind-a-reverse-proxy
>
> http://serverfault.com/questions/121766/webdav-rename-fails-on-an-apache-mod-dav-install-behind-nginx
>
> http://serverfault.com/questions/17239/joomlas-extplorer-ssl-seems-to-be-broken?rq=1
> http://forum.joomla.org/viewtopic.php?p=1776489
>
> http://www.turnkeylinux.org/forum/support/20101213/fileserver-appliance-behind-forwarding-proxy
>
>
> On Sunday, July 1, 2012 at 11:01 AM, Daniel Ruggeri wrote:
>
> > On 7/1/2012 2:40 AM, Clinton J. Campbell wrote:
> > > I know that this is not an unusual combo, fronting an unencrypted
> httpd with a proxy accepting connections over https, and the server seems
> to handle receiving https URI's within headers for GET requests. So I guess
> I'm still curious whether there is a way to configure httpd to prevent the
> redirection to http on the POST?
> > >
> > > There's one remaining twist in the logs, that also makes me wonder if
> the problem is coming from Joomla. I ran a scenario lifting the restriction
> to https and I connected unencrypted to the server. After the POST, the
> server responds in the same fashion, with an HTTP 303. Is this a standard
> pattern for httpd with POST requests or is it something that is likely
> being triggered by the application?
> >
> > Yes, I think you are getting closer. The important distinction to make
> > is that httpd is not authenticating the user - it's the application
> > (Joomla) running inside httpd. I have seen this before in other
> > applications that generate a URL for redirects or links based on the
> > connection it received. Luckily, in my case, I was able to trick the
> > backend container into thinking it's speaking https by setting some
> > headers. It sounds like the application is receiving the credentials and
> > then just sending along the redirect for the user to make it to the
> > admin landing page. Unfortunately, it's using the scheme (http) used
> > when talking to httpd as part of that location header rather than
> > creating a relative or server-relative redirect.
> >
> > In this scenario, there are three options.
> > *Adjust how the application behaves (there may be a config setting
> > controlling this)
> > *Modify the response as it passes through one of the two proxies. In
> > httpd, we would use ProxyPassReverse for this situation - not sure what
> > Squid has
> > *Self-sign and install some certs on the 'inside' httpd instance so it
> > will be over SSL (thus tricking the app)
> >
> > The challenge with the second option is that you might solve this
> > particular problem but could create new ones or find another stumbling
> > block one step further into the process... and the next thing you know
> > you may have a mess of complicated config settings you don't want to
> > touch in the future for fear of breaking something.
> >
> > --
> > Daniel Ruggeri
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org (mailto:
> users-unsubscribe@httpd.apache.org)
> > For additional commands, e-mail: users-help@httpd.apache.org (mailto:
> users-help@httpd.apache.org)
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
Or just dump Squid which seams is not appropriate for your Joomla case and
use Apache instead. It takes 15 minutes to set Apache as reverse proxy.
Re: [users@httpd] Apache modifies URL when offloading SSL
Posted by "Clinton J. Campbell" <cl...@gmail.com>.
Thanks Daniel (and others) for the help along the way. I've landed on pretty much the same conclusion as I've continued researching. The additional insight about the redirects helped me craft my searches more specifically. I figure I ought to share some of my conclusions for anybody who might stumble upon this thread in their own searches later.
I only mentioned one of the scenarios giving me trouble in detail, but there are actually three distinct problems now that I know the redirects are originating at the application level.
Joomla Administration -- It looks like my best options will be #1 from Daniel's reply (adjust application behavior) or #3 (use backend SSL connection to trick the application). Option #3 will require additional virtual hosts and the challenge will be ensuring the proxy directs the traffic properly between the encrypted and unencrypted instances. If I happen to send unencrypted traffic to the encrypted backend, I'm afraid I might end up with similar redirects causing undesirable behavior. The workload on these servers is relatively low, so I'm leaning toward #3 since it will minimize the administrative burden going forward.
Joomla Plugins (extplorer) -- I'm hopeful that option #3 will resolve my issues for Joomla plugins, though I may need to look more deeply into option #1 here as well.
WebDAV -- I believe I'm limited to option #2 (rewrite the response at the proxy) and option #3. Again I'm leaning toward #3 since it is the easiest administratively. If the traffic load increases down the road, I may reconsider.
Finally, here are some references I intend to consult as I go forward:
http://stackoverflow.com/questions/1110710/webdav-behind-a-reverse-proxy
http://serverfault.com/questions/121766/webdav-rename-fails-on-an-apache-mod-dav-install-behind-nginx
http://serverfault.com/questions/17239/joomlas-extplorer-ssl-seems-to-be-broken?rq=1
http://forum.joomla.org/viewtopic.php?p=1776489
http://www.turnkeylinux.org/forum/support/20101213/fileserver-appliance-behind-forwarding-proxy
On Sunday, July 1, 2012 at 11:01 AM, Daniel Ruggeri wrote:
> On 7/1/2012 2:40 AM, Clinton J. Campbell wrote:
> > I know that this is not an unusual combo, fronting an unencrypted httpd with a proxy accepting connections over https, and the server seems to handle receiving https URI's within headers for GET requests. So I guess I'm still curious whether there is a way to configure httpd to prevent the redirection to http on the POST?
> >
> > There's one remaining twist in the logs, that also makes me wonder if the problem is coming from Joomla. I ran a scenario lifting the restriction to https and I connected unencrypted to the server. After the POST, the server responds in the same fashion, with an HTTP 303. Is this a standard pattern for httpd with POST requests or is it something that is likely being triggered by the application?
>
> Yes, I think you are getting closer. The important distinction to make
> is that httpd is not authenticating the user - it's the application
> (Joomla) running inside httpd. I have seen this before in other
> applications that generate a URL for redirects or links based on the
> connection it received. Luckily, in my case, I was able to trick the
> backend container into thinking it's speaking https by setting some
> headers. It sounds like the application is receiving the credentials and
> then just sending along the redirect for the user to make it to the
> admin landing page. Unfortunately, it's using the scheme (http) used
> when talking to httpd as part of that location header rather than
> creating a relative or server-relative redirect.
>
> In this scenario, there are three options.
> *Adjust how the application behaves (there may be a config setting
> controlling this)
> *Modify the response as it passes through one of the two proxies. In
> httpd, we would use ProxyPassReverse for this situation - not sure what
> Squid has
> *Self-sign and install some certs on the 'inside' httpd instance so it
> will be over SSL (thus tricking the app)
>
> The challenge with the second option is that you might solve this
> particular problem but could create new ones or find another stumbling
> block one step further into the process... and the next thing you know
> you may have a mess of complicated config settings you don't want to
> touch in the future for fear of breaking something.
>
> --
> Daniel Ruggeri
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org (mailto:users-unsubscribe@httpd.apache.org)
> For additional commands, e-mail: users-help@httpd.apache.org (mailto:users-help@httpd.apache.org)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Apache modifies URL when offloading SSL
Posted by Daniel Ruggeri <DR...@primary.net>.
On 7/1/2012 2:40 AM, Clinton J. Campbell wrote:
> I know that this is not an unusual combo, fronting an unencrypted httpd with a proxy accepting connections over https, and the server seems to handle receiving https URI's within headers for GET requests. So I guess I'm still curious whether there is a way to configure httpd to prevent the redirection to http on the POST?
>
> There's one remaining twist in the logs, that also makes me wonder if the problem is coming from Joomla. I ran a scenario lifting the restriction to https and I connected unencrypted to the server. After the POST, the server responds in the same fashion, with an HTTP 303. Is this a standard pattern for httpd with POST requests or is it something that is likely being triggered by the application?
Yes, I think you are getting closer. The important distinction to make
is that httpd is not authenticating the user - it's the application
(Joomla) running inside httpd. I have seen this before in other
applications that generate a URL for redirects or links based on the
connection it received. Luckily, in my case, I was able to trick the
backend container into thinking it's speaking https by setting some
headers. It sounds like the application is receiving the credentials and
then just sending along the redirect for the user to make it to the
admin landing page. Unfortunately, it's using the scheme (http) used
when talking to httpd as part of that location header rather than
creating a relative or server-relative redirect.
In this scenario, there are three options.
*Adjust how the application behaves (there may be a config setting
controlling this)
*Modify the response as it passes through one of the two proxies. In
httpd, we would use ProxyPassReverse for this situation - not sure what
Squid has
*Self-sign and install some certs on the 'inside' httpd instance so it
will be over SSL (thus tricking the app)
The challenge with the second option is that you might solve this
particular problem but could create new ones or find another stumbling
block one step further into the process... and the next thing you know
you may have a mess of complicated config settings you don't want to
touch in the future for fear of breaking something.
--
Daniel Ruggeri
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org