Apache with PFS and SNI

This is more a quick note-to-self than a comprehensive article. There are already tons of articles out there about setting up PFS or SNI. Here are some useful links:

PFS:

SSL Settings analyzer: https://www.ssllabs.com/ssltest/ (of course, your website needs to be reachable on the internet)
Good settings for Apache Cipher Suites: http://ggramaize.wordpress.com/2013/08/02/tls-perfect-forward-secrecy-support-with-apache/

SNI:

Apache httpd wiki on SNI: https://wiki.apache.org/httpd/NameBasedSSLVHostsWithSNI
Apache httpd wiki on name-based vhosts and SSL: https://wiki.apache.org/httpd/NameBasedSSLVHosts

My Settings for PFS:

Since I mostly need the server to have a secure connection myself (for editing content and to avoid password transmission in clear text), I break a few super old browsers (like IE6 on XP) with these settings:

SSLProtocol +TLSv1.2 +TLSv1.1 +TLSv1
SSLCompression off
SSLHonorCipherOrder on
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-RC4-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:RC4-SHA:AES256-GCM-SHA384:AES256-SHA256:CAMELLIA256-SHA:ECDHE-RSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:CAMELLIA128-SHA:!aNULL:!eNULL:!EXP:!LOW:!MD5

Update (08/2014):

I use the following settings now, slightly adapted from https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy. RC4 is completely disabled, so only use this for sites which only tech-savy people are going to visit. Otherwise, use the configuration below where RC4 is enabled, but you will not get an A+ from ssllabs.com.

SSLProtocol all -SSLv2 -SSLv3
SSLCompression off
SSLHonorCipherOrder on
SSLCipherSuite EECDH+ECDSA+AES256+GCM:EECDH+aRSA+AES256+GCM:EECDH+ECDSA+AES128+GCM:EECDH+aRSA+AES128+GCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:EDH+aRSA:CAMELLIA:AES:!RC4:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS

With RC4, better compatibility with IE6 to IE8 (which you should not use anymore!!!):

SSLProtocol all -SSLv2 -SSLv3
SSLCompression off
SSLHonorCipherOrder on
SSLCipherSuite EECDH+ECDSA+AES256+GCM:EECDH+aRSA+AES256+GCM:EECDH+ECDSA+AES128+GCM:EECDH+aRSA+AES128+GCM:EECDH+ECDSA+SHA384:EECDH+ECDSA+SHA256:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH+aRSA+RC4:EECDH:EDH+aRSA:CAMELLIA:AES:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS

Note that you need httpd version 2.4+ (not sure if 2.3?) for this to work. You can put this into every virtual host statement or (better, cleaner, easier because it does not need to be remembered for every new vhost): put it into the global ssl config. Where this is depends on your linux distribution.

How to get SNI to work

SNI is mostly a client side issue (the browser has to support it, of course, the server too). Read up on it on the httpd wiki linked above. Server-side it is just configuring separate certificates/keys per virtual host. Note that you only need SNI if the virtual hosts run on the same socket (if you did not know that then really read the doc first or you will end up with a horrible mess).

So this is basically what a virtual host looks like here: 001-subdomain.example.com.conf

Note that the first VirtualHost is for the non-https, the second one for the https connection. You might want to turn off the SeverSignature - it "leaks" your server version (but that can also be determined by numerous other things). The Directory statements for ".git" are nice to have if you are using git for webpage version control and want to avoid people sifting through your git stuff. Now if you have multiple VirtualHost directives, let's say another one for a web2.example.net, one more for web3.example.net etc. you can just copy the above and basically replace "web1" by "web2" everywhere. Note that httpd will (should) ask your for a password for each SSLCertificateKeyFile - if you are encrypting them (you should). The downside is that the server will not start without someone entering the password, which is a slight problem after an unplanned reboot (e.g. after a power outage). However, if your server gets hacked, completely pwned, the keys are still safe because they are encrypted. You should also use really long and strong passwords, since you will not need them often anyway, and write them down or save them in a password safe which you store at a secure location.