You cannot put multiple SSL-enabled virtual Apache hosts onto the same IP and port.
Apache cannot identify which VirtualHost to serve a request from because the payload is encrypted in its entirety. So a
Host: servertwo.tldheader cannot be parsed until the encryption has been removed. Which requires the key, which is listed in the VHost section that could not be identified in the first place...
So a name-based VirtualHost-configuration like this won't work:
- Listen 443
- NameVirtualHost *:443
- <virtualhost>
- SSLEngine On
- ServerName serverone.tld:443
- SSLCertificateFile /etc/apache2/ssl/serverone.crt
- SSLCertificateKeyFile /etc/apache2/ssl/serverone.key
- [...]
- </virtualhost>
- <virtualhost>
- SSLEngine On
- ServerName servertwo.tld:443
- SSLCertificateFile /etc/apache2/ssl/servertwo.crt
- SSLCertificateKeyFile /etc/apache2/ssl/servertwo.key
- [...]
- </virtualhost>
It will just serve any request out of the first VirtualHost (serverone.tld) regardless of the hostname in the request headers.
There is some light at the end of this tunnel though:
RFC4366 describes an optional field to the TLS (Transport Layer Security) client request called "Server Name Indication" (SNI). With this the client just includes a list of ServerNames (usually one) that it's trying to contact. Apache can easily match the supplied name from the client against a ServerName (or ServerAlias) directive from it's configuration files.
SNI will be supported with OpenSSL v0.9.9 in mod_ssl. Sometime in the future. There is a backport to v0.9.8 available from Steven Henson linked here. Or you can use mod_gnutls as described by George Notaras in a recent blog entry.
In either cases the above configuration snippet will "just work" once SNI is understood by Apache.
Currently Internet Explorer 7 (on Vista only, wanna upgrade
), Mozilla Firefox 2+, Opera 7.6+, KDE Konqueror 3.5+ support sending the SNI. You can test your browser at Kaspar Brand's SNI testpage. He also has a patch available to make Apache 2.2 mod_ssl SNI capable when compiled against a CVS-version of OpenSSL.I'm rather sure that spreading SNI capable hosts will also provide new hacking opportunities:
Let's assume a system serves both Intranet and Internet traffic. A client contacts the Internet IP with SSL but specifies the Intranet Hostname in it's TLS SNI entry. Guess what will happen? Yup.
I don't see the problem. That host has one Virtual Host for each hostname, each has its own certificate and its own access rules.
The Intranet Virtual Host should already be filtering out incoming traffic from the internet.
If it isn't, there was a security issue previous to the use of SNI, just as serious and exploitable as before.
Luckily a lot of reverse proxies terminate SSL connections on the proxy and open a new connection to the destination host. This will break all SNI functionality (as the proxies don't even know about this functionality yet) but will also only allow access to the default SSL VHost as the SNI tag does not get through to the destination host.
Those who have saved on computing power and forward SSL connections without interim termination or use port forwarding, are at risk though.
The "servername" is determined from a callback out of the TLS library to Apache ("ssl_servername_cb"), then a patched Apache sets the context ("ssl_set_vhost_ctx") and finally checks the hostname that came from the client against the available vhosts ("set_ssl_vhost").
Thus separate (name based) VHosts won't help you, separate certificates won't either (the attacker will see the other certificate as his/her first indication of success). Access rules will help, but as stated above, I've not seen them being used as a default anywhere. That has to change, if one deploys SNI in a DMZ scenario.
ServerName internal.myserver.org
ServerAdmin root@myserver.org
ProxyRequests Off
ProxyPreserveHost On
SSLProxyEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /etc/apache2/ssl/internal.myserver.org.crt
SSLCertificateKeyFile /etc/apache2/ssl/internal.myserver.org.key
ErrorLog /var/log/apache2/ssl_error_log
TransferLog /var/log/apache2/ssl_access_log
Order deny,allow
Allow from all
ProxyPass /sharedfiles/ https://internal.myserver.org/sharedfiles/
ProxyPassReverse /sharedfiles/ https://myserver.org/sharedfiles/
ProxyPass /myapp/ https://internal.myserver.org/myapp/
ProxyPassReverse /myapp/ https://myserver.org/myapp/
am i doing something really wrong here?