So you’ve rated your web server’s SSL configuration with SSL Labs.
First thing to do
Briefly search through results to see if:
- SSL 2.0 is enabled.
- export or weak cipher suites are enabled.
- even worst: anonymous cipher suites, or null encryption cipher suites are enabled.
- MD5 based cipher suites are enabled.
- an MD5 based signature algorithm was used to sign your certificate.
- your certificate is not valid: expired, issued by a not trusted CA(this may be acceptable if you use a private CA for private users), etc.
- client side initiated insecure renegotiation is enabled.
If so, you have a poorly SSL configuration on your site.
Hint: some of the above will trigger a bad grade(if it’s yellow it’s so-so; if it’s red it’s ouch).
Second thing you should do
Ignore the score; you should only care about the grade, A would be desired.
Why?
You may ask, as you see some 97-98 scores and may want get a higher score too.
Those results are likely of no use in practice; probably just done for testing, show off or so. They not necessarily show a high security SSL configuration in the context of the current rating system.
On the other hand the A grade should give you a decent security baseline.
Hint: Typically the average site is configured for performance + security + interoperability; with all these in equal proportions.
Protocols
- TLS 1.0 must be enabled.
- SSL 3.0 should be enabled if you are having old browsers such as Internet Explorer 6.0 accessing your site.
- SSL 2.0 must be disabled as it is weak and its use is prohibited per RFC 6176.
- TLS 1.1 and TLS 1.2, if supported by your server, may be enabled; however very unlikely to be used by current browsers(unless this is a private server and you control the client side as well).
Certificate
- use a certificate with a RSA key size of 2048-bits(DSA or ECDSA certificates are rare in practice today).
- a certificate with a RSA key size of 1024-bits is still acceptable but you should avoid it.
- a certificate with a RSA key size greater than 2048-bits offers little overall security at the cost of increased CPU cycles.
- also such a certificate will mean more data to be sent by the server to the client as the server will send its certificate to the client and this certificate will contain the big public RSA key, thus potentially increased latency.
- the signature algorithm must not be MD5 with RSA; SHA1 with RSA is acceptable; SHA2 family with RSA is not common today.
- the RSA public and private keys are generated locally on your side typically when you create the CSR(Certificate Signing Request); make sure you use a strong provider with enough entropy to avoid weak keys like the Debian case ones.
- at least OCSP should be available for certificate revocation status checks(the de facto used by modern bowsers); if CRL support is also provided even better.
- make sure you obtain the certificate from a popular CA, thus increasing the chances to be trusted by most browsers.
- also the CA should not have many intermediate certificates as this might create chain issues when all will not be sent(in the correct order) or will introduce latency when this chain becomes too large.
- for browsers there is no difference between a Domain Validated certificate or an Organization Validated one; if you want to inspire greater confidence to your users get an extended validation certificate.
Cipher suites
- first: make sure you do not enable anonymous or NULL encryption cipher suites in a production environment; also the export ones must not be used.
- you typically look for the combination: authenticated key exchange(e.g. RSA or DHE-RSA) + cipher(e.g. AES or RC4) + MAC(e.g. SHA).
- as authenticated key exchanges: RSA, DHE-RSA, ECDHE-RSA are OK(ECDHE-ECDSA is rarely used in practice for the moment).
- as ciphers: AES(128-bit and 256-bit), 3DES and RC4 are fine. Additionally Camellia is acceptable. Weak ciphers like DES must not be used.
- for MAC: SHA1 is decent, MD5 should be avoided(SHA2 family based MACs are rare in practice today).
- remember: RC4 is the fastest cipher if compared with AES or 3DES, offers great interoperability but is not FIPS approved; 3DES is the slowest but is FIPS approved and offers great interoperability; AES is FIPS approved, greatly supported by browsers(only old ones like IE6 will not support it) and offers good performance and security(these vary per used key size).
- also the overall performance of a cipher suite is given by the combination: authenticated key exchange + cipher + MAC[ + underling hardware(e.g Intel CPU with AES NI instructions set)].
- do use server side cipher suite order preference, as it will allow you to balance your server for best performance + security + interoperability; for example Apache 2.2.x has no server side preferred cipher suite, but this can be adjusted.
- if you want to use cipher suites that offer PFS, you can use DHE based ones or ECDHE based ones; the later are faster but not supported by all major browsers(Opera does not support ECC); note that 2048-bit DHE exchanges may put some pressure on your hardware.
Miscellaneous
- patch the server to support the secure renegotiation extension and disable the insecure one; additionally if not needed by your application, disable the client side initiated renegotiation.
- do enable the SSL session resumption feature as it will potentially save round trips and CPU cycles.
- make sure the underling hardware is appropriate; if you don’t use a dedicated hardware SSL solution you may choose an Intel processor with the AES NI instructions set(the crypto library must be able to make use of these).
- remember the SSL part’s of your server overall speed is a combination of: cipher suite speed + session resumption ability + certificate revocation status check + server certificate and chain size + underlying hardware + crypto library.