Until the day TLS 1.3 becomes widely supported, web servers must rely on a fallback to TLS 1.2 with correctly configured server directives and strong cipher suites. Pick the wrong settings, and you declare an open season on your server.
The basics of TLS
The Transport Layer Security protocol (TLS) can secure communications between parties and is widely used with a variety of application-level protocols.
The bad news is that all versions of TLS, except for TLS 1.3 as of this writing, have been compromised in one way or another and their fatal flaws are widely documented.
TLS 1.3 is expected to do away with some of the most dangerous vulnerabilities of its predecessors.
TLS configuration involves quite a few steps. Here is what you need to do.
Step 1. Find out which cipher suites your server supports
In cryptography, an algorithm that performs encryption or decryption is called a cipher (or cypher). A cipher suite is a combination of such algorithms that provides a set of required features, namely key exchange, authentication, encryption (including the cipher and cipher mode) and message authentication (MAC). All these algorithms and additional security settings have to be negotiated between the parties—the client and the server—in order to establish a secure network connection tunnel using the Transport Layer Security (TLS) protocol.
The cipher suites that your system supports depend on the installed version of your cryptographic library.
Various crypto libraries such as OpenSSL, IANA and GnuTLS use slightly different names for the same cipher suites. Be careful when you edit you server’s configuration file. You want to use the correct syntax for your system.
To figure out the best parameters for your application, find out what cipher suites your system supports. With OpenSSL, use this command (or check the reference):
/usr/bin/openssl ciphers -s -v
The resulting list reveals the names of cipher suites and their capabilities:
- the protocol version (only TLS 1.3 and TLS 1.2 with certain cipher suites are considered trustworthy)
- key exchange algorithm (Diffie-Hellman, ECDH or Elliptic Curve Diffie-Hellman, SRP, PSK — do NOT use RSA!)
- authentication mechanism (DSA, ECDSA, RSA)
- bulk cipher (e.g. CHACHA20, AES128-GCM)
- cryptographic message authentication code (e.g. SHA384, POLY1305)
The general composition of the names of cipher suites conforms to the logic:
Beware of abbreviated cipher suite designations. For example,
AES256-SHA256 will activate RSA (by implication) as both the key exchange algorithm and the authentication algorithm and the cipher mode CBC (Cipher Block chaining). WARNING: Do NOT use RSA for the key exchange! Do NOT use CBC, it’s been compromised time and time again. Avoid abbreviated cipher suites.
The components of a cipher suite
The key exchange algorithm uses asymmetric encryption to determine how the client and server will authenticate during the TLS handshake. The sender uses a public key of the recipient for encrypting. The recipient uses its private key to decrypt the message it receives.
The authentication mechanism confirms the identity of the server during the TLS handshake.
Asymmetric encryption serves to digitally sign and exchange a secret key. This key can then be used with a symmetric key algorithm (the bulk cipher) to encrypt the actual data.
The bulk cipher algorithm uses symmetric encryption to secure the channel by encrypting and decrypting the transmission. Bulk ciphers fall into one of two categories:
- stream ciphers operate on data one byte at a time (RC4 is a stream cipher)
- block ciphers operate on blocks of data of equal length (DES and AES are examples of block ciphers) using a symmetric secret key.
Block ciphers can operate in cipher block chaining mode (CBC for short). CBC was thought to counteract manipulation as the data integrity of each block depends on the proper encryption of the block before it. The CBC IV for each record except the first is the previous records’ last ciphertext block. Faulty implementations of CBC in TLS 1.0 allowed for the emergence of the BEAST attack (see “Attack vectors against TLS and its implementation vulnerabilities” for more). The prevalence of those faulty implementations prompted the removal of CBC from TLS 1.3.
The MAC algorithm (short for Message Authentication Code, or HMAC for Hashed Message Authentication Code) creates a message digest or cryptographic hash of each message exchanged in the secure channel in order to ensure data integrity.
Step 2. Activate cipher suites for TLS 1.3
TLS 1.3 requires you to specify the following AEAD (Authenticated Encryption with Associated Data) ciphers:
TLS13-CHACHA20-POLY1305-SHA256 TLS13-AES-256-GCM-SHA384 TLS13-AES-128-GCM-SHA256
You may tweak the order, but you should activate all three of the above.
For TLS 1.2, things are a bit more complicated.
Step 3. Configure TLS 1.2 with only the strongest cipher suites
When it comes to TLS 1.2, the quality of cipher suites varies greatly. This presents somewhat of a risk. Should even a single weak cipher suite find its way into your configuration, you would be in trouble.
In terms of the key exchange in TLS 1.2, you have two basic choices:
- ECDHE: an elliptic-curve Diffie-Hellman key exchange; it can be signed with either Elliptic Curve Digital Signature Algorithm ECDSA (ECDHE-ECDSA) or RSA (ECDHE-RSA). Either one is acceptable.
- DHE: a normal Diffie-Hellman key exchange.
Do NOT use RSA for the key exchange! (For example:
OpenSSL DES-CBC3-SHA, IANA TLS_RSA_WITH_3DES_EDE_CBC_SHA, are bad choices!)
DHE is slower than ECDHE. If you are concerned about performance, prioritize ECDHE-ECDSA over DHE. OWASP estimates that the TLS handshake with DHE hinders the CPU by a factor of 2.4 compared to ECDHE.
Top choices for secure ciphers
As of this writing, your first choice among TLS 1.2 cipher suites are the following ones (in OpenSSL syntax):
These somewhat older cipher suites are also acceptable:
ChaCha20/Poly1305 has somewhat of a performance advantage over AES on CPUs that don’t have a built-in support for AES (typically in mobile devices). Thus, your server should only opt for ChaCha20/Poly1305 when the client device declares such a preference. Otherwise, your server should use AES.
The above listed cipher suites may not suffice in terms of your clients’ compatibility requirements, though.
Additional cipher suites recommended for broader compatibility
If high compatibility with a variety of user agents is of concern, consider adding these cipher suites:
and finally these:
You will need to check these settings periodically to take advantage of future improvements. (It’s probably not what you wanted to hear, but as of now, vigilance is still a requirement for cyber security.)
Step 4. Test your setup
To test your web server setup, you can use Qualys Labs’ online SSL Server Test located at:
The tool simulates session negotiation with your web server by a variety of user agents. This way, you can see which of your select cipher suites are ordinarily in use. This way you can tweak your server’s configuration and discard cipher suites you no longer need.
TLS 1.3 final draft:
Pentest-Tools: Scan your server for the POODLE, DROWN, ROBOT, Bash Shellshock/Ghost, Heartbleed and more: