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.

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.