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@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|