SSL/TLS best practices for websites
Keeping Secrets
4. Protocols
A public website must support the TLS 1.0, TLS 1.1, and TLS 1.2 protocols. SSL 2 is obsolete and insecure. SSL 3 is also deprecated and, although it is not inherently insecure, it lacks many important features of more modern protocols. Therefore, it is a good idea to disable SSL 3 if there is no special reason to keep it. Nearly all clients support at least TLS version 1.0.
5. Cipher-SuitePreference
The ability to specify cipher suites that the server should use by preference is a very useful feature. Because TLS ensures the integrity of the handshake, the attacker cannot use the preference mechanism to stipulate weaker encryption.
6. Choice ofCipher Suite
I recommend strong ciphers that implement 128-bit encryption. This list includes AES and Camellia, but AES offers the advantage that it can be used with authenticated suites that support GCM mode. And, AES is faster. Authenticated suites are your best option for TLS and avoid potentially insecure cipher-block chaining suites. 3DES offers 112 bits strength and is suitable for interoperability with older clients. You should avoid RC4, which is insecure.
You will also want to steer clear of cipher block chaining suites that use SHA-256 and SHA-384 to validate integrity. These options are noticeably slower than SHA-1 and offer no significant security advantages. The shortcomings are irrelevant in SHA-1 in this case, because validation relies on HMAC. SHA-256 and SHA-384 are also nominally GCM suites, but because they work differently from authenticated suites, the performance difference is not noticeable.
For a key exchange via ECDHE, the secp256r1
curve offers the best performance and 128-bit security. Other curves are a lot slower or poorly supported. Compared to DHE, ECDHE is always preferable for achieving good performance even with a 2048-bit key length.
Admins should steer clear of the RSA key exchange, unless circumstances force their hand, because it does not offer forward secrecy. It is safer to search for the abbreviation ECDHE or DHE in the name of the cipher suite. This helps you achieve forward secrecy, which means that each individual connection to the site is protected with an individual key.
Without forward secrecy, the security of all connections depends on the confidentiality of the server's private key. Should the private key ever be stolen or cracked, a hacker can retroactively decrypt sniffed network traffic.
For OpenSSL version 1.0.1 with elliptic-curve cryptography enabled, based on all these considerations, it is advisable to choose the suites from Listing 1 in the stated order. The collection is divided into two groups by an empty line. If you have a group of users with modern software, you can ignore the last five suites because they use the RSA key exchange and offer no forward secrecy. Add RC4-SHA at the end if it is essential for interoperability.
Listing 1
Cipher Suites
01 ECDHE-ECDSA-AES128-GCM-SHA256 02 ECDHE-ECDSA-AES256-GCM-SHA384 03 ECDHE-RSA-AES128-GCM-SHA256 04 ECDHE-RSA-AES256-GCM-SHA384 05 DHE-RSA-AES128-GCM-SHA256 06 DHE-RSA-AES256-GCM-SHA384 07 ECDHE-ECDSA-AES128-SHA 08 ECDHE-ECDSA-AES256-SHA 09 ECDHE-ECDSA-DES-CBC3-SHA 10 ECDHE-RSA-AES128-SHA 11 ECDHE-RSA-AES256-SHA 12 ECDHE-RSA-DES-CBC3-SHA 13 DHE-RSA-AES128-SHA 14 DHE-RSA-AES256-SHA 15 EDH-RSA-DES-CBC3-SHA 16 17 AES128-GCM-SHA256 18 AES256-GCM-SHA384 19 AES128-SHA 20 AES256-SHA 21 DES-CBC3-SHA
Listings later in this article demonstrate the configuration of these suites for specific servers.
Buy this article as PDF
(incl. VAT)