Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Apache: Dev

Fwd: [users@httpd] SNI with apache 2.4.1 reverse proxy

 

 

Apache dev RSS feed   Index | Next | Previous | View Threaded


DRuggeri at primary

Apr 6, 2012, 3:34 PM

Post #1 of 14 (2808 views)
Permalink
Fwd: [users@httpd] SNI with apache 2.4.1 reverse proxy

I wanted to bring this up here - seems like a few things are going on
that are confusing to me. I'll try to look into it when time becomes
available, but I thought someone might have an opinion off the bat.

-------- Original Message --------
Subject: [users [at] http] SNI with apache 2.4.1 reverse proxy
Date: Fri, 6 Apr 2012 14:11:50 +0200
From: Michael Weiser <michael [at] dinsnail>
Reply-To: users [at] httpd
To: users [at] httpd



Hello,

after upgrading from 2.2.21 to 2.4.1 I'm seeing a problem with SNI in
combination with reverse proxying.

I have a VM with wordpress in it behind an apache reverse proxy. The
reverse proxy runs on the host system and port 12443 of this host is
forwarded into the VM and connects to 443 there. The reverse proxy
configuration lives in a virtual host that redirects all requests for a
number of different server names/aliases to port 12443 and thus into the
VM.

The working HTTPS reverse proxy configuration of httpd 2.2 looks like
this:

<VirtualHost *:443>
DocumentRoot /var/www/www.example.com

ServerName www.example.com
ServerAlias example.com *.example.com
ErrorLog /var/log/apache2/www.example.com-ssl_error_log
CustomLog /var/log/apache2/www.example.com-ssl_access_log combined
UserDir disable

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/ssl/certs/www.example.com.httpscert.pem
SSLCertificateKeyFile /etc/ssl/private/www.example.com.httpskey.unenc
SSLCACertificateFile /etc/ssl/certs/www.example.com.pem

ProxyRequests Off
ProxyPass / https://www.example.com:12443/
ProxyPassReverse / https://www.example.com:12443/

SSLProxyEngine on
SSLProxyCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLProxyCACertificateFile /etc/ssl/certs/cacert.pem
SSLProxyCheckPeerCN On
SSLProxyCheckPeerExpire On
SSLProxyVerify require
SSLProxyVerifyDepth 1
</VirtualHost>

Apart from the port change, this setup isn't very VM-specific.
Therefore, the problem I'm seeing should hit any SSL reverse proxy setup
where multiple frontend names are forwarded to the same backend server
via a static ProxyPassReverse URL.

After upgrading to 2.4.1, when accessing subdomain.example.com, the
apache inside the VM logs:

[Fri Apr 06 11:23:55 2012] [error] Hostname www.example.com provided
via SNI and hostname subdomain.example.com provided via HTTP are different

My guess was that 2.4.1's mod_ssl now uses SNI towards the backend as
well and indeed there's the following code in ssl_engine_io.c that's not
in 2.2.21:

#ifndef OPENSSL_NO_TLSEXT
/*
* Enable SNI for backend requests. Make sure we don't do it for
* pure SSLv3 connections, and also prevent IP addresses
* from being included in the SNI extension. (OpenSSL would simply
* pass them on, but RFC 6066 is quite clear on this: "Literal
* IPv4 and IPv6 addresses are not permitted".)
*/
if (hostname_note &&
sc->proxy->protocol != SSL_PROTOCOL_SSLV3 &&
apr_ipsubnet_create(&ip, hostname_note, NULL,
c->pool) != APR_SUCCESS) {
[...]

Having seen this, I added

SSLProxyProtocol SSLv3

to the reverse proxy configuration to disable usage of SNI and indeed
the setup now works again with 2.4.1.

Is there an explicit configuration option for en-/disabling usage of SNI
towards the proxy backend servers? Should there be (I think yes)?

Also I realise that the problem is more fundamental: What if I wanted to
host multiple sites inside the VM and actually use SNI? Therefore I
tried configuring the reverse proxy with a dynamic backend URL like
this:

ProxyRequests Off
SetEnvIf Host (.*) reverse_proxy_host=$1
ProxyPass / https://${reverse_proxy_host}:12443/ interpolate
ProxyPassReverse / https://${reverse_proxy_host}:12443/ interpolate
ProxyPreserveHost On
ProxyPassInterpolateEnv On

This however does not work: The reverse proxy gives an error and logs
the following for all requests:

[Fri Apr 06 13:00:30.275588 2012] [ssl:debug] [pid 20237:tid 139649156212480] ssl_engine_kernel.c(243): [client 79.215.31.101:53195] AH02034: Initial (No.1) HTTPS request received for child 0 (server www.example.com:443)
[Fri Apr 06 13:00:30.275588 2012] [authz_core:debug] [pid 20237:tid 139649156212480] mod_authz_core.c(809): [client 79.215.31.101:53195] AH01628: authorization result: granted (no directives)
[Fri Apr 06 13:00:30.275588 2012] [core:info] [pid 20237:tid 139649156212480] [client 79.215.31.101:53195] AH00128: File does not exist: proxy:https://blog.example.com:12443/

The proxy initialisation also looks hinky:

[Fri Apr 06 13:00:29.791558 2012] [proxy:debug] [pid 20237:tid 139649224263488] proxy_util.c(1640): AH00925: initializing worker https://${reverse_proxy_host}:12443/ shared
[Fri Apr 06 13:00:29.791558 2012] [proxy:debug] [pid 20237:tid 139649224263488] proxy_util.c(1680): AH00927: initializing worker https://${reverse_proxy_host}:12443/ local
[Fri Apr 06 13:00:29.791558 2012] [proxy:debug] [pid 20237:tid 139649224263488] proxy_util.c(1712): AH00930: initialized pool in child 20237 for (${reverse_proxy_host}) min=0 max=25 smax=25

Also I realise that blindly using the request's Host header for reverse
proxying isn't the most secure thing to do.

What would be the proper way to go about this?
--
Thank you,
Micha

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe [at] httpd
For additional commands, e-mail: users-help [at] httpd


httpd-dev.2012 at velox

Apr 6, 2012, 11:20 PM

Post #2 of 14 (2701 views)
Permalink
Re: Fwd: [users@httpd] SNI with apache 2.4.1 reverse proxy [In reply to]

On 07.04.2012 00:34, Daniel Ruggeri wrote:
> I wanted to bring this up here - seems like a few things are going on
> that are confusing to me. I'll try to look into it when time becomes
> available, but I thought someone might have an opinion off the bat.
>
> -------- Original Message --------
> Subject: [users [at] http] SNI with apache 2.4.1 reverse proxy
> Date: Fri, 6 Apr 2012 14:11:50 +0200
> From: Michael Weiser <michael [at] dinsnail>
> Reply-To: users [at] httpd
> To: users [at] httpd

[...]

> [Fri Apr 06 11:23:55 2012] [error] Hostname www.example.com provided
> via SNI and hostname subdomain.example.com provided via HTTP are different

Seems like mod_ssl is not getting the "proper" host name in the
"proxy-request-hostname" note... from a quick glance at the "working
HTTPS reverse proxy configuration of httpd 2.2", he is obviously trying
to forward the whole domain to port 12443 on the same machine (note
the "*.example.com" ServerAlias):

> <VirtualHost *:443>
> DocumentRoot /var/www/www.example.com
>
> ServerName www.example.com
> ServerAlias example.com *.example.com
[...]
> ProxyPass / https://www.example.com:12443/
> ProxyPassReverse / https://www.example.com:12443/

Then it looks like mod_proxy_http determines the value for
"proxy-request-hostname" from the remote URL in ProxyPass, but is
passing on the Host header from the original request.

Kaspar


i.galic at brainsware

Apr 9, 2012, 1:56 AM

Post #3 of 14 (2694 views)
Permalink
Re: [users@httpd] SNI with apache 2.4.1 reverse proxy [In reply to]

----- Original Message -----
> On 07.04.2012 00:34, Daniel Ruggeri wrote:
> > I wanted to bring this up here - seems like a few things are going
> > on
> > that are confusing to me. I'll try to look into it when time
> > becomes
> > available, but I thought someone might have an opinion off the bat.
> >
> > -------- Original Message --------
> > Subject: [users [at] http] SNI with apache 2.4.1 reverse proxy
> > Date: Fri, 6 Apr 2012 14:11:50 +0200
> > From: Michael Weiser <michael [at] dinsnail>
> > Reply-To: users [at] httpd
> > To: users [at] httpd
>
> [...]
>
> > [Fri Apr 06 11:23:55 2012] [error] Hostname www.example.com
> > provided
> > via SNI and hostname subdomain.example.com provided via HTTP are
> > different
>
> Seems like mod_ssl is not getting the "proper" host name in the
> "proxy-request-hostname" note... from a quick glance at the "working
> HTTPS reverse proxy configuration of httpd 2.2", he is obviously
> trying
> to forward the whole domain to port 12443 on the same machine (note
> the "*.example.com" ServerAlias):
>
> > <VirtualHost *:443>
> > DocumentRoot /var/www/www.example.com
> >
> > ServerName www.example.com
> > ServerAlias example.com *.example.com
> [...]
> > ProxyPass / https://www.example.com:12443/
> > ProxyPassReverse / https://www.example.com:12443/
>
> Then it looks like mod_proxy_http determines the value for
> "proxy-request-hostname" from the remote URL in ProxyPass, but is
> passing on the Host header from the original request.

That would imply ProxyPreserveHost on -- which is off by default
I also don't see it in Micha's paste.

> Kaspar

i

--
Igor Galić

Tel: +43 (0) 664 886 22 883
Mail: i.galic [at] brainsware
URL: http://brainsware.org/
GPG: 6880 4155 74BD FD7C B515 2EA5 4B1D 9E08 A097 C9AE


michael at weiser

Apr 10, 2012, 1:01 AM

Post #4 of 14 (2700 views)
Permalink
Re: [users@httpd] SNI with apache 2.4.1 reverse proxy [In reply to]

Hi Igor,
Hi Daniel,

On Mon, Apr 09, 2012 at 08:56:12AM -0000, Igor Gali? wrote:

> > Then it looks like mod_proxy_http determines the value for
> > "proxy-request-hostname" from the remote URL in ProxyPass, but is
> > passing on the Host header from the original request.
> That would imply ProxyPreserveHost on -- which is off by default
> I also don't see it in Micha's paste.

Uh, I am very sorry to have wasted your time, but I actually do have

ProxyPreserveHost On

in my config. It was inbetween some comments and I must have removed it
together with them. I have checked and it seems to be the only
statement missing from my mail.

I have it in there because wordpress has a feature of automatically
using the host name from the request in all links in the HTML it
generates. Unfortunately, it insists on creating absolute instead of
relative links. This is also why I access wordpress inside the VM via
HTTPS at all: This way it automatically (or at least with only a
very small patch to it's config.php) generates https:// links in its
responses when accessed via HTTPS, making the reverse proxy very simple
(apart from the SSL bit) and almost transparent.

At first I tried to configure the reverse proxy to plain http:// (SSL
termination, so to speak) and rewrite all links using mod_proxy_html for
performance and because it seemed the straightforward thing to do. But I
had various detail problems within wordpress I couldn't solve (with
links to uploaded files for example). So I switched to just passing on
the original requests as unchanged as possible.

As for the SNI bit: So I tell the reverse proxy to access
https://www.example.com:12433/ but pass on the Host header unchanged.
The wordpress VM's apache 2.2.14 gets upset with this discrepancy and
denies to serve the requests. As I perhaps poorly explained in the
second part of my mail, I tried to tell the reverse proxy to access
https://<Host-header>:12443/ instead but couldn't make it work.

A solution might be something like:

ProxyPass / https://www.example.com:12443/ no-sni
ProxyPassReverse / https://www.example.com:12443/ no-sni

, disabling SNI towards the backend server.

Or can I tell the 2.2.14 apache inside the VM to ignore the SNI data it
sees in the requests?

The best solution I can think of would be some switch like

ProxyPass / https://www.example.com:12443/ pass-host-as-sni
ProxyPassReverse / https://www.example.com:12443/ pass-host-as-sni

that makes mod_ssl put the content of the host header into the sni data
structures instead of the hostname from the URL used in the
ProxyPass(Reverse) configuration itself. This way even name-based
virtual hosts should work behind the reverse proxy.
--
Thanks for your patience,
Micha


michael at weiser

Apr 16, 2012, 3:45 AM

Post #5 of 14 (2682 views)
Permalink
Re: [users@httpd] SNI with apache 2.4.1 reverse proxy [In reply to]

Hi,

On Tue, Apr 10, 2012 at 10:01:11AM +0200, Michael Weiser wrote:

> A solution might be something like:

> ProxyPass / https://www.example.com:12443/ no-sni
> ProxyPassReverse / https://www.example.com:12443/ no-sni

> , disabling SNI towards the backend server.

> Or can I tell the 2.2.14 apache inside the VM to ignore the SNI data it
> sees in the requests?

> The best solution I can think of would be some switch like

> ProxyPass / https://www.example.com:12443/ pass-host-as-sni
> ProxyPassReverse / https://www.example.com:12443/ pass-host-as-sni

> that makes mod_ssl put the content of the host header into the sni data
> structures instead of the hostname from the URL used in the
> ProxyPass(Reverse) configuration itself. This way even name-based
> virtual hosts should work behind the reverse proxy.

I haven't heard anything back: What's the general opinion on this?
--
bye, Micha


peter.sylvester at edelweb

Apr 16, 2012, 4:45 AM

Post #6 of 14 (2669 views)
Permalink
Re: [users@httpd] SNI with apache 2.4.1 reverse proxy [In reply to]

On 04/16/2012 12:45 PM, Michael Weiser wrote:
>
>> that makes mod_ssl put the content of the host header into the sni data
>> structures instead of the hostname from the URL used in the
>> ProxyPass(Reverse) configuration itself. This way even name-based
>> virtual hosts should work behind the reverse proxy.
> I haven't heard anything back: What's the general opinion on this?
2 pfennige:

- If a configuration parameter can be avoided, this divides
the possibilities of errors by at least 3.
I don't think that a configuration parameter is necessary.

- If something is put into the SNI, it must be identical to
what is in the Host:header.


/PS


michael at weiser

Apr 16, 2012, 7:47 AM

Post #7 of 14 (2667 views)
Permalink
Re: [users@httpd] SNI with apache 2.4.1 reverse proxy [In reply to]

Hi there,

On Mon, Apr 16, 2012 at 01:45:16PM +0200, Peter Sylvester wrote:

> >> that makes mod_ssl put the content of the host header into the sni data
> >> structures instead of the hostname from the URL used in the
> >> ProxyPass(Reverse) configuration itself. This way even name-based
> >> virtual hosts should work behind the reverse proxy.
> > I haven't heard anything back: What's the general opinion on this?
> - If a configuration parameter can be avoided, this divides
> the possibilities of errors by at least 3.
> I don't think that a configuration parameter is necessary.

I agree (or at least don't care as long as I get the behaviour I need ;).

> - If something is put into the SNI, it must be identical to
> what is in the Host:header.

This could be a side-effect of ProxyPreserveHost On since only with
ProxyPreserveHost On does it make any sense anyways. With
ProxyPreserveHost Off, the SNI data should contain the hostname from the
ProxyPassReverse directive.

So implementation-wise this will most likely have two parts of code:

1. Determining the hostname to put into SNI data depending on
ProxyPreserveHost somewhere in the reverse proxy module.

2. Putting that value into the SNI data in mod_ssl's ssl_engine_io.c.

ssl_engine_io.c already uses an apr_table_get with a name of
proxy-request-hostname which is apr_table_set'd in mod_proxy_http.c. So
point 2 seems to be taken care of already. Host header preservation seems
to be done done in mod_proxy_http.c as well. Now setting
proxy-request-hostname based on that shouldn't be too hard.

Shall I have a go at that?
--
bye, Michael
Elephants don't play chess!


tevans.uk at googlemail

Apr 16, 2012, 8:02 AM

Post #8 of 14 (2665 views)
Permalink
Re: [users@httpd] SNI with apache 2.4.1 reverse proxy [In reply to]

On Mon, Apr 16, 2012 at 3:47 PM, Michael Weiser
<michael [at] weiser> wrote:
> Hi there,
>
> On Mon, Apr 16, 2012 at 01:45:16PM +0200, Peter Sylvester wrote:
>
>> >> that makes mod_ssl put the content of the host header into the sni data
>> >> structures instead of the hostname from the URL used in the
>> >> ProxyPass(Reverse) configuration itself. This way even name-based
>> >> virtual hosts should work behind the reverse proxy.
>> > I haven't heard anything back: What's the general opinion on this?
>> - If a configuration parameter can be avoided, this divides
>>    the possibilities of errors by at least 3.
>>    I don't think that a configuration parameter is necessary.
>
> I agree (or at least don't care as long as I get the behaviour I need ;).
>
>> - If something is put into the SNI, it must be identical to
>>    what is in the Host:header.
>
> This could be a side-effect of ProxyPreserveHost On since only with
> ProxyPreserveHost On does it make any sense anyways. With
> ProxyPreserveHost Off, the SNI data should contain the hostname from the
> ProxyPassReverse directive.

Er, surely you mean "ProxyPass directive" here. The ProxyPassReverse
directive is only used for rewriting response headers, it has nothing
to do with altering the proxied request.

Cheers

Tom


michael at weiser

Apr 16, 2012, 9:49 AM

Post #9 of 14 (2667 views)
Permalink
Re: [users@httpd] SNI with apache 2.4.1 reverse proxy [In reply to]

Hi Tom,

On Mon, Apr 16, 2012 at 04:02:00PM +0100, Tom Evans wrote:

> > This could be a side-effect of ProxyPreserveHost On since only with
> > ProxyPreserveHost On does it make any sense anyways. With
> > ProxyPreserveHost Off, the SNI data should contain the hostname from the
> > ProxyPassReverse directive.

> Er, surely you mean "ProxyPass directive" here. The ProxyPassReverse
> directive is only used for rewriting response headers, it has nothing
> to do with altering the proxied request.

To be honest, I'm making this all up as I go along. Thanks for pointing
me in the right direction.
--
Thanks,
Micha


httpd-dev.2012 at velox

Apr 18, 2012, 1:16 AM

Post #10 of 14 (2653 views)
Permalink
Re: [users@httpd] SNI with apache 2.4.1 reverse proxy [In reply to]

On 16.04.2012 16:47, Michael Weiser wrote:
> So implementation-wise this will most likely have two parts of code:
>
> 1. Determining the hostname to put into SNI data depending on
> ProxyPreserveHost somewhere in the reverse proxy module.
>
> 2. Putting that value into the SNI data in mod_ssl's ssl_engine_io.c.

I'm not too familiar with the history/motivation of the
ProxyPreserveHost directve (which dates to as far as 2002, see r93089),
but in the context of proxy SSL requests, I think it isn't a
particularly good idea to support this feature... because essentially,
it opens up the door to MitM attacks: you're asking mod_proxy_http to,
say, request URI https://foo.example.org/index.html, but directing it
via TLS to a host configured with certificate bar.example.org.

mod_proxy_http's "blindness" for MitM attacks was also the reason for
introducing SSLProxyCheckPeerCN in r760866/r768504, I assume. In
addition to dealing with SNI extension / Host header mismatches you
would also have to accommodate for the case of CN / Host header mismatches.

To solve your immediate problem in 2.4, what you could try is:

ProxyPass / https://127.0.0.1:12443/
ProxyPreserveHost On
SSLProxyCheckPeerCN off

This prevents mod_ssl in 2.4 from adding an SNI extension to the proxy
request (it will skip IP addresses), and will pass the Host reader from
the original request to the backend. You need to turn off
SSLProxyCheckPeerCN at the same time (unless your backend cert has
CN=127.0.0.1) - but in the end, this just reflects what you're asking
mod_proxy_http to do: connect via TLS to host with cert X and request
resource from host Y.

Kaspar


michael at weiser

Apr 23, 2012, 8:11 AM

Post #11 of 14 (2664 views)
Permalink
Re: [users@httpd] SNI with apache 2.4.1 reverse proxy [In reply to]

Hello Karspar,
Hi all,

On Wed, Apr 18, 2012 at 10:16:51AM +0200, Kaspar Brand wrote:

> > So implementation-wise this will most likely have two parts of code:
> >
> > 1. Determining the hostname to put into SNI data depending on
> > ProxyPreserveHost somewhere in the reverse proxy module.
> >
> > 2. Putting that value into the SNI data in mod_ssl's ssl_engine_io.c.
> I'm not too familiar with the history/motivation of the
> ProxyPreserveHost directve (which dates to as far as 2002, see r93089),
> but in the context of proxy SSL requests, I think it isn't a
> particularly good idea to support this feature... because essentially,
> it opens up the door to MitM attacks: you're asking mod_proxy_http to,
> say, request URI https://foo.example.org/index.html, but directing it
> via TLS to a host configured with certificate bar.example.org.

I don't think so: I'm not directing the Proxy to connect to a different
host. I just make it send different SNI data to the configured backend
server and accept a different CN in the server's certificate. The MitM
would still have to hijack the server's IP or DNS entry and present a
certificate issued by a trusted CA for that CN, just that it now has to
read bar.example.org instead of foo.example.org. I don't see, how the
attack gets simpler by that.

I am, however, not sure how the change will affect forward proxying (if
at all). I have only thought about reverse proxying where I have
SSLProxyVerify set to require on the reverse proxy and run both servers
with a self-signed CA for just that purpose. All the client-side
presentation is done by the reverse proxy with the official certificates.

> mod_proxy_http's "blindness" for MitM attacks was also the reason for
> introducing SSLProxyCheckPeerCN in r760866/r768504, I assume. In
> addition to dealing with SNI extension / Host header mismatches you
> would also have to accommodate for the case of CN / Host header mismatches.

That's done automatically since the same note is used for CN check and
SNI data. By setting that note to the hostname from the Host header,
all there items are in sync automatically.

I've put together a small patch doing just that (admittedly without much
knowing what I'm doing since its my very first time hacking apache).
I've opened a bug report for it:
https://issues.apache.org/bugzilla/show_bug.cgi?id=53134. Feel free to
have a look at it and tell me what you think. Perhaps it also helps to
make clear, what I mean.

With that patch name based virtual hosts work with SSL through an
httpd-2.4/trunk reverse proxy with a single virtual host and no rewrite
rules whatsoever on both servers.

> To solve your immediate problem in 2.4, what you could try is:

> ProxyPass / https://127.0.0.1:12443/
> ProxyPreserveHost On
> SSLProxyCheckPeerCN off

> This prevents mod_ssl in 2.4 from adding an SNI extension to the proxy
> request (it will skip IP addresses), and will pass the Host reader from
> the original request to the backend. You need to turn off
> SSLProxyCheckPeerCN at the same time (unless your backend cert has
> CN=127.0.0.1) - but in the end, this just reflects what you're asking
> mod_proxy_http to do: connect via TLS to host with cert X and request
> resource from host Y.

I've chosen the second possible workaround: Setting SSLProxyProtocol to
SSLv3. If you look at the code in ssl_engine_io.c you'll see that its
the second condition for disabling SNI towards the backend server. This
way, SSLProxyCheckPeerCN can stay enabled.
--
Micha
I hate forms!


httpd-dev.2012 at velox

Apr 29, 2012, 12:59 AM

Post #12 of 14 (2614 views)
Permalink
Re: [users@httpd] SNI with apache 2.4.1 reverse proxy [In reply to]

On 23.04.2012 17:11, Michael Weiser wrote:
> I don't think so: I'm not directing the Proxy to connect to a different
> host. I just make it send different SNI data to the configured backend
> server and accept a different CN in the server's certificate.

I guess it boils down to the question of what the semantics of ProxyPass
are / should be. Currently, the docs say (for 2.0/2.2./2.4):

> This directive allows remote servers to be mapped into the space of
> the local server; the local server does not act as a proxy in the
> conventional sense, but appears to be a mirror of the remote server.
> _path_ is the name of a local virtual path; _url_ is a partial URL for
> the remote server and cannot include a query string.

With the patch you proposed in PR 53134, the docs about ProxyPass would
have to be amended with something like: "If ProxyPreserveHost is turned
on, the host component of _url_ is used to determine what host to
connect to at the network layer, but is otherwise ignored (only the
scheme and path components are taken into account)."

Whether that is desired or not probably depends on a judgement of
possible use cases. As far as I'm concerned, I'm not convinced that
there are really good reasons for "playing the ProxyPreserveHost trick"
(neither for https nor for http, actually), but YMMV.

Kaspar


ruediger.pluem at vodafone

Apr 30, 2012, 12:15 AM

Post #13 of 14 (2624 views)
Permalink
RE: [users@httpd] SNI with apache 2.4.1 reverse proxy [In reply to]

> -----Original Message-----
> From: Kaspar Brand [mailto:httpd-dev.2012 [at] velox]
> Sent: Sonntag, 29. April 2012 09:59
> To: dev [at] httpd
> Subject: Re: [users [at] http] SNI with apache 2.4.1 reverse proxy
>
> Whether that is desired or not probably depends on a judgement of
> possible use cases. As far as I'm concerned, I'm not convinced that
> there are really good reasons for "playing the ProxyPreserveHost trick"
> (neither for https nor for http, actually), but YMMV.

The main reason I see for the "ProxyPreserveHost trick" is a reverse proxy setup,
where the backend application builds full qualified links into its HTML output based
on the information it gets from the Host header. The only other approach in this case
I can think of would be working with host entries on the reverse proxy to resolve the name
of the reverse proxy to the IP of the backend which is not really nice either.

Regards

Rüdiger


tevans.uk at googlemail

May 3, 2012, 9:37 AM

Post #14 of 14 (2609 views)
Permalink
Re: [users@httpd] SNI with apache 2.4.1 reverse proxy [In reply to]

On Mon, Apr 30, 2012 at 8:15 AM, Plüm, Rüdiger, Vodafone Group
<ruediger.pluem [at] vodafone> wrote:
>> -----Original Message-----
>> From: Kaspar Brand [mailto:httpd-dev.2012 [at] velox]
>> Sent: Sonntag, 29. April 2012 09:59
>> To: dev [at] httpd
>> Subject: Re: [users [at] http] SNI with apache 2.4.1 reverse proxy
>>
>> Whether that is desired or not probably depends on a judgement of
>> possible use cases. As far as I'm concerned, I'm not convinced that
>> there are really good reasons for "playing the ProxyPreserveHost trick"
>> (neither for https nor for http, actually), but YMMV.
>
> The main reason I see for the "ProxyPreserveHost trick" is a reverse proxy setup,
> where the backend application builds full qualified links into its HTML output based
> on the information it gets from the Host header. The only other approach in this case
> I can think of would be working with host entries on the reverse proxy to resolve the name
> of the reverse proxy to the IP of the backend which is not really nice either.
>

All of our sites (229 and counting) are generated by application
servers that are reversed proxied by a main Apache server, and every
single one of them uses ProxyPreserveHost for precisely this reason.

Cheers

Tom

Apache dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.