httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Igor Cicimov <icici...@gmail.com>
Subject Re: [users@httpd] Apache modifies URL when offloading SSL
Date Sun, 01 Jul 2012 23:51:21 GMT
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.

Mime
View raw message