I've been playing around a lot with SSL/TLS server settings. I'll explain what settings I used for this https connection and how they improve your security.
This site passes the Qualys SSL Server Test with 100 points. When I started this page, most browsers were unable to access it, but nowadays luckily most browsers support TLS 1.2 with GCM-modes. This page is accessible with https and many fancy TLS settings through https://fancyssl.hboeck.de and with less strict TLS settings through https://fancynossl.hboeck.de.
What? Only connections through the latest TLS 1.2 are allowed.
Why? TLS 1.1 and all versions before only support algorithms using SHA-1, which is know to be cryptographically weak since 2005.
TLS 1.2 is the only version that supports AES in GCM (Galois/Counter Mode).
Also, TLS 1.0 and earlier are vulnerable to the BEAST attack. This can be mitigated, but then you loose other important security features like Perfect Forward Secrecy.
Browser support: Getting better, most browsers support TLS 1.2 now, but not all support the stronger AES256 encryption modes.
Browsers known to work: iPhone/iPad integrated browser, lynx, w3m, midori, probably more these days.
Server support: Can be enabled in current apache with the SSLProtocol directive (as I'm writing this 2.2.23 and 2.4.3 are current) if the system has openssl 1.0.1 or above:
SSLProtocol -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 +TLSv1.2
Not exactly a security feature, but an option to have more than one certificate on one IP. Usually, today's webservers run dozents of virtual hosts on one IP. This made SSL implementation difficult in the past, as traditional SSL requires one IP per certificate and the domain name is fixed in the certificate. The Server Name Indication, available since TLS 1.0, allows to circumvent this restriction (although there are some problems with browsers due to backwards compatibility, see this Mozilla bug).
Browser support: Pretty much every modern browser, with one exception: The still widely used Android 2.x versions don't support SNI in the default browser. Android 3.x and above are okay.
Server support: Using Apache 2.2.12 or above you can specify a certificate in every vhost with SSLCertificateFile, SSLCertificateKeyFile and, if neccessary, SSLCertificateChainFile.
TLS compression is insecure and allows the CRIME attack, so it's disabled. It's mostly unsupported by browsers anyway. Data can still be compressed on the HTTP layer with HTTP compression.
Certificate is signed by Let's Encrypt, because its free ;-)
It has a 2048 bit RSA key and a signature with SHA256. (Originally I had a 4096 bit certificate, but it is too much hassle to support this with our certificate automation and 2048 is more than enough.) RSA keys with 1024 bit are considered insecure for very rich attackers, keys with 768 bit are very insecure and keys with 512 bit are ridiculous. That said, Google, PayPal, Amazon, Yahoo, eBay, Apple, Twitter and a bunch of others still used 512 bit keys in 2012 (for DKIM, not for https). In 2010, the EFF found 512 bit RSA certificates on https with so-called "Extended Validation" (EV), which is forbidden by the EV rules.
Keys with 2048 bit or above are considered secure.
Also, we've correctly installed the certificate chain. This should be obvious, but it is not. Very often, wrongly installed chains can remain undetected for a long time, because browsers are lax when the chain is in wrong order and if it's completely missing, the browser will take intermediate certificates it has cached from other sites.
A hughe problems with certificates are revocations. The CRL or OCSP protocols should allow browsers to check certificate authorities if certificates are still valid. However, browsers either disable OCSP or implement it in an insecure way treating "no reply" as "everything's fine". Also, OCSP has privacy issues, because the certificate authority will get all the IPs from users checking their certs. So it's basically broken and useless, but that's the way things are.
With OCSP stapling, the server caches the certificate authorities OCSP reply and bundles it into the SSL connection. This improves performance and privacy when using OCSP.
We send the HTTP Strict Transport Security header, which tells the browser to access this page only with SSL for a certain timeframe and thus makes SSL stripping attacks less likely. The timeout is set to two years.
In 2009, a flaw was found in the SSL/TLS renegotiation feature. A TLS-extension specified in RFC 5746 allows renegotiation without the flaw.
Apache used fixed parameters for Diffie-Hellman key exchanges with 1024 bit. That's considered insecure, however there's no way in Apache before version 2.4.7 to change this except disabling DH exchanges at all. Apache 2.4.7 and above set the DH size to the certificate key size, which is a good idea.
Every SSL connection uses a specific set of algorithms. The server offers a list of them and a client can choose one. We restricted our algorithms to ones that use a key exchange - EDH or ECDH - because this provides so-called Perfect Forward Secrecy.
We only support algorithms with SHA256 and SHA384, because SHA-1 is considered insecure and everything before (like MD5, MD4, MD2, SHA-0) is considered totally broken. If you don't believe me: Microsoft didn't believe MD5 insecurities are a hughe issue either - and they got the Flame Virus in response.
There are some reservations about the security of AES, so we only use the longer AES-256 variant (although this is somewhat questionable - there are theoretical attacks that only work against AES-258 and not against AES-128). There's no symmetric cipher except AES that can be used by SSL/TLS with a secure hash function, so RC4, Triple-DES and others are all out.
AES can be used in different modes. TLS 1.2 supports CBC (Cipher-block chaining) and GCM (Galois/Counter Mode). Lately, CBC increasingly came under attack (see BEAST and Lucky Thirteen), so I completely disabled all CBC ciphersuites.
What could be implemented to further improve security:
This test site was setup by Hanno Böck. All
content may be considered CC0 / Public Domain.