httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaspar Brand <>
Subject Re: [users@httpd] SNI with apache 2.4.1 reverse proxy
Date Wed, 18 Apr 2012 08:16:51 GMT
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, but directing it
via TLS to a host configured with certificate

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 /
        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= - 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.


View raw message