The link you refer to is … well … nice, but neither ‘correct’ nor perfect. And so is your setup.
• He uses ‘ECDH’ and ‘DH’ in the ciphers where he should use ‘ECDHE’ and ‘DHE’ instead. Perhaps he hasn’t understood that there are actually non-PFS key exchange mechanisms available in some ciphers actually which could be caught by these specifiers.
• His bashing of ECDSA is not adequate these days. Support for cheap ECC (ECDSA) certificates is there, and setup is just as easy as the setup of an RSA certificate.And the string would not increase at all since most of the well-written pattern matching specifiers would hit comparable ECDSA ciphers and RSA ciphers without modification. Some browsers like IE before Win10 would actually benefit from ECDSA keys as they support more recent ciphers with that kind of key, like
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c), which they do not support with RSA keys. Another benefit of ECDSA keys: DHE is completely gone and with it the dhparam file.
• Disabling DSS at the end is just stupid and obfuscates the pattern string unnecessarily. Without a DSA key, no DSA/DSS cipher would be chosen anyway.
• In total, he offers way too many ciphers.
Consequently, you’re offering 21 ciphers of which the listed web clients/browsers use a total of 9. The other 12 are completely useless and can be excluded from the list of offered ciphers: The less ciphers you have, the smaller is the attack vector if one of these unused ciphers is found to be vulnerable. Here is the list of ciphers you are offering but no client will ever use if he is not specially crafted to ignore better ciphers:
Of the remaining ciphers 4 are used by ancient clients only. As you seem to be running OwnCloud I would suppose you tie it with some personally known PCs and recent smartphones, so we should be able to rule out these ancient clients and with them the ciphers required for supporting them:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) (Android 2.3)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) (IE8/XP)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) (Java 7u25)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) (OpenSSL 0.9.8)
Note: Of these four, you could think about enabling the DHE and ECDHE ciphers one by one if you really, really need them. However, I would definitely go for FS-only ciphers before supporting IE8/XP with its inferior RSA key exchange. And, yes, of the remaining three only Android 2.3 cannot upgrade. Java7 and OpenSSL 0.9.8 based clients should definitely go forward. It’s about time.
Leaves us with a list of a total of 5 ciphers actually used by current clients.
The respective cipher list can be described easiest as
Some people insist that we’re in big trouble with AES256 compared to AES128. If you’re still wearing that same tinfoil hat you should limit your cipher list to AES128:
As a side effect, this reduces the number of ciphers you offer to just 4 but increases your client coverage by Java7.
Finally, three more things you can optimize in your setup:
Add HSTS headers to your https server as I saw that http calls are already redirected to https. This would reward you an A+ instead of A by SSL Labs.
You should disable HTTP compression for fixing BREACH (CVE-2013-3587).
You could raise your score on Key Exchange by following http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslcertificatefile and appending strong dhparam and ECparam values to your certificate. However, your server string is indicating Apache 2.2.22 which might not yet support this feature.
Note: later, when ECDSA keys are supported by LE (or when you can afford a fortune of about $13 total for a three-year DV ECDSA key) the SSLCipherSuite wouldn’t have to change at all for supporting the new key. But since DHE is not supported with ECDSA keys, you could drop this non-matching pattern so that the cipher string could become as short as the following:
or, if you insist on pushing AES128 instead of AES256, a single pattern is sufficient to match the three ciphers you’d need: