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.<\/p>\n
<\/p>\n
The Transport Layer Security protocol (TLS) can secure communications between parties and is widely used with a variety of application-level protocols.<\/p>\n
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<\/a>.<\/p>\n TLS serves three main objectives: authenticate peers, prevent eavesdropping, and tamper-proof their communications by validating the authenticity of messages. Different algorithms serve different purposes.\u00a0<\/span><\/p>\n During the initial negotiation, the client and server have to agree on a set of parameters that define how the communication channel will be secured, and exchange session keys in order to establish a secure channel.\u00a0This is the handshake<\/strong> phase.<\/p>\n The TLS handshake establishes one or more input secrets<\/strong>. The\u00a0key derivation algorithm<\/strong>combines these input secrets to create the actual working keying material. This process relies on both the input secrets and the transcript of the handshake itself.<\/p>\n During the handshake, the peers rely on\u00a0asymmetric encryption<\/strong>. The sender uses the recipient’s\u00a0public key<\/strong>\u00a0to encrypt a message. The recipient uses its own\u00a0private key<\/strong>\u00a0to decrypt it upon receipt. During the handshake, the peers perform a key exchange to open a secure channel.<\/p>\n The key derivation process in TLS 1.3 relies on the HKDF-Extract and HKDF-Expand functions and the Hash function of the cipher suite.<\/p>\n Prior to the key exchange, the client and server use HKDF to generate the keys. (It replaces PRF, a pseudo-random key derivation function based on (H)MAC.)<\/p>\n To sign the keys that are exchanged during the initial handshake, TLS uses a signature algorithm. The signature algorithm takes a plaintext\u00a0message<\/em>\u00a0(not a hash) and outputs a signature; any hashing is part of the signature algorithm.<\/p>\n TLS 1.3 allows the signature algorithms<\/p>\n To confirm the identity of the server (and optionally, the client) during the TLS handshake,\u00a0the protocol uses an\u00a0authentication mechanism<\/strong>.<\/p>\n To confirm the authenticity of individual messages, the sender computes a message authentication code using (H)MAC.<\/p>\n The key exchange algorithm<\/strong>\u00a0determines how the client and server authenticate during a TLS handshake<\/strong>. The key that they exchange may then be used with a symmetric encryption algorithm\u2014the bulk cipher\u2014to encrypt the actual data in the secure channel.<\/p>\n In order to keep the communication a secret, TLS opens a secure channel in which all data sent and received is encrypted.<\/p>\n The secure channel relies on symmetric encryption<\/strong>: the encryption and the decryption keys are identical. Those keys have been exchanged during the TLS handshake in\u00a0a procedure called TLS key exchange<\/strong>.<\/p>\n In cryptography, an algorithm that performs encryption or decryption is called a cipher\u00a0<\/strong>(or cypher).<\/p>\n A cipher suite<\/strong>\u00a0is 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).<\/p>\n TLS 1.3 separates the authentication and key exchange methods from the\u00a0TLS record protection algorithm\u2014the bulk cipher\u2014and the hash function.<\/p>\n The\u00a0bulk cipher<\/b>\u00a0algorithm uses symmetric\u00a0<\/strong>encryption<\/b>\u00a0to secure the channel by encrypting and decrypting the transmission.<\/p>\n Bulk ciphers fall into one of two categories:<\/p>\n An example of a cipher suite based on a safe stream cipher is TLS13-CHACHA20-POLY1305-SHA256 in TLS 1.3. (TLS 1.3 disallows the use of the stream cipher RC4.)<\/p>\n Examples of cipher suites based on a block cipher include TLS13-AES-128-GCM-SHA256 and TLS13-AES-256-GCM-SHA384 in TLS 1.3.<\/p>\n The MAC algorithm<\/strong> (short for Message Authentication Code)\u00a0<\/em>creates a message digest or a cryptographic hash of each message exchanged in the secure channel in order to\u00a0ensure data integrity.<\/p>\n HMAC<\/strong>\u00a0(Hashed Message Authentication Code<\/em>) is a type of\u00a0MAC involving a\u00a0cryptographic hash function\u00a0and a secret\u00a0cryptographic key and is designed\u00a0to simultaneously verify both the data integrity and the authenticity of a message in the secure channel.\u00a0By using the session key as the HMAC key, the sender of a message can produce a hash of its payload in a way that cannot be forged by anyone unless they know the session key, thus allowing the client to verify its authenticity.<\/p>\n Cryptographic\u00a0hash functions are public functions (they do not use a secret key) that offer collision-resistance. Collision resistance means that it is hard to find two messages with the same hash (a useful property for the purposes of authentication).<\/p>\n MACs are keyed functions that can counteract message forgery\u00a0so long as the key remains a secret.\u00a0HMAC is believed to retain the collision resistance of the underlying hash function even in the event that the MAC key is compromised.<\/p>\n Since it is not sufficient to merely authenticate a message but also to prevent eavesdropping, the (H)MAC algorithm has to combine with the cipher that encrypts the payload. TLS 1.2 and its predecessors use a technique called MAC-then-Encrypt. The sender authenticates its plaintext message using a MAC algorithm, then encrypts the authenticated data. The recipient first decrypts the data using the session key, then verifies its authenticity.\u00a0This approach has a major downside in that it allows an unauthenticated attacker to send arbitrary messages and force the receiving endpoint to decrypt garbage that would fail the MAC verification\u2014a lot of work for nothing.<\/p>\n An Encrypt-then-MAC configuration would make a lot more sense. This technique first encrypts the message, then computes the MAC of the ciphertext so as to confirm its authenticity. As a result, the recipient can easily discard messages that don’t check out as authentic, since the attacker cannot forge the MAC without knowing the session key. Encrypt-then-Mac would close the padding oracle vulnerability. Unfortunately, Encrypt-then-MAC\u00a0is notoriously difficult to implement.<\/p>\n The architects of TLS 1.3 opted for a third way: AEAD cipher suites. These cipher suites compute MAC and encrypt simultaneously, eliminating the padding oracle vulnerability\u2014hopefully once and for all.<\/p>\n TLS configuration involves quite a few steps. Here is what you need to do.<\/p>\n The cipher suites that your system supports depend on the installed version of your cryptographic library.<\/p>\n Various crypto libraries such as OpenSSL<\/strong>, IANA<\/strong> and\u00a0GnuTLS<\/strong> 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.<\/p>\n 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<\/a>):<\/p>\n The resulting list reveals the names of cipher suites and their capabilities:<\/p>\n The general composition of the names of cipher suites in TLS 1.2 conforms to the logic:<\/p>\n Beware of abbreviated cipher suite designations. For example,\u00a0 WARNING: Do NOT use RSA for the key exchange! Do NOT use the CBC block cipher mode, it’s been compromised<\/a> time and time again. Avoid abbreviated naming conventions in cipher suites configuration unless you really know what you are doing.\u00a0<\/span><\/p>\n TLS 1.3 requires that you specify the following AEAD (Authenticated Encryption with Associated Data) ciphers:<\/strong><\/p>\n You may tweak the order, but you should activate all three of the above.<\/p>\n For TLS 1.2, things are a bit more complicated.<\/p>\n 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.<\/p>\n In terms of the key exchange in TLS 1.2, you have two basic choices:<\/p>\n Do NOT use RSA for the key exchange!\u00a0<\/span>(For example: DHE is slower than\u00a0ECDHE. If you are concerned about performance, prioritize\u00a0ECDHE-ECDSA over DHE. OWASP estimates that the TLS handshake with DHE hinders the CPU by a factor of 2.4 compared to ECDHE.<\/p>\n As of this writing, your first choice among TLS 1.2 cipher suites are the following ones (in OpenSSL syntax):<\/p>\n ECDHE-ECDSA-CHACHA20-POLY1305-SHA256 These somewhat older cipher suites are also acceptable:<\/p>\n DHE-RSA-AES256-GCM-SHA384 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.<\/p>\n The above listed cipher suites may not<\/strong> suffice in terms of your clients’ compatibility requirements, though.<\/p>\n If high compatibility with a variety of user agents is of concern, consider adding these cipher suites:<\/p>\n DHE-RSA-AES256-SHA256 and finally these:<\/p>\n ECDHE-RSA-AES256-SHA 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.)<\/p>\n To test your web server setup, you can use Qualys Labs’ online SSL Server Test located at:<\/p>\nThe TLS handshake<\/h3>\n
Key derivation and authentication<\/h3>\n
\n
Key exchange<\/h3>\n
The secure TLS channel<\/h3>\n
Ciphers and cipher suites<\/h2>\n
The components of a cipher suite<\/h3>\n
The bulk cipher<\/h3>\n
\n
(H)MAC<\/h3>\n
Collision resistance of the hash function<\/h4>\n
MAC-then-Encrypt versus AEAD cipher suites<\/h3>\n
How to configure TLS for security (plus performance and compatibility)<\/h1>\n
Step 1. Find out which cipher suites your server supports<\/h2>\n
\/usr\/bin\/openssl ciphers -s -v<\/pre>\n
\n
KeyExchange:Authentication:Cipher[:CipherMode]:MAC<\/pre>\n
AES256-SHA256<\/del> will activate the insecure RSA algorithm (by implication) for both the key exchange and authentication, and use the vulnerable cipher mode CBC (Cipher Block chaining). <\/span><\/p>\nStep 2. Activate cipher suites for TLS 1.3<\/h2>\n
TLS13-CHACHA20-POLY1305-SHA256\r\nTLS13-AES-256-GCM-SHA384\r\nTLS13-AES-128-GCM-SHA256<\/pre>\n
Step 3. Configure TLS 1.2 with only the strongest cipher suites<\/h2>\n
\n
OpenSSL DES-CBC3-SHA, IANA TLS_RSA_WITH_3DES_EDE_CBC_SHA<\/del>,\u00a0 are bad choices!)<\/em><\/span><\/p>\nTop choices for secure ciphers<\/h3>\n
\nECDHE-ECDSA-CHACHA20-POLY1305
\nECDHE-ECDSA-AES256-SHA384
\nECDHE-ECDSA-AES128-SHA256
\nECDHE-RSA-CHACHA20-POLY1305<\/p>\n
\nDHE-RSA-AES128-GCM-SHA256
\nECDHE-RSA-AES256-GCM-SHA384
\nECDHE-RSA-AES128-GCM-SHA256<\/p>\nAdditional cipher suites recommended for broader compatibility<\/h3>\n
\nDHE-RSA-AES128-SHA256
\nECDHE-RSA-AES256-SHA384
\nECDHE-RSA-AES128-SHA256<\/p>\n
\nECDHE-RSA-AES128-SHA
\nDHE-RSA-AES256-CCM8
\nDHE-RSA-AES256-CCM<\/p>\nStep 4. Test your setup<\/h2>\n