Cipher suite selection Step 3: SSL Options and Cipher Suites

121 protocol unable to perform key exchange. It follows that static keying is not even an option for DSA-based certificates; we must supplement them with ephemeral keys. The second advantage of using temporary keys is that they provide forward secrecy. At a high level, forward secrecy means that if the private key is obtained by a third party, that third party will not be able to decode previous sessions conducted with that key or even future sessions conducted by someone else with the compromised key. This is due to the ephemeral keys used for the secrecy of the sessions. When using static keys, there is no forward secrecy since the secrecy of the key exchange, and hence the following transmission stream, is based on the private key. With an ephemeral key, the data on which the key exchange was performed no longer exists after the key exchange, and thus the session remains private regardless of private key compromise. Thus, forward secrecy means that private key compromise will only allow an attacker to masquerade as the key owner, but not access the key owners private data. These two points make the benefits of using ephemeral keying clear. In the case of DSA certificates, its necessary for the protocol to succeed, and in the case of RSA certificates, it affords us forward secrecy. In terms of SSL, using ephemeral keys essentially mandates that the keys embedded in the certificates shall be used only for signatures and not for encryption. Understanding this, it seems as though weve left a hole in the protocol since we do not have a method for key exchange. OpenSSL provides two options: temporary RSA keys or Diffie- Hellman DH key agreement. Of these two choices, DH is better because temporary RSA keys violate the SSLTLS protocols. The RSA keying was originally implemented to make sure export restrictions on cryptography were not violated. [1] Today, this issue is not a primary concern; thus, ephemeral RSA keys tend not to be used. Additionally, generation of these temporary RSA keys is much slower than using DH, presuming the DH parameters are pre-generated. [1] Export restrictions once required weak RSA keys for encryption, but stronger keys were acceptable for signing. In order to allow OpenSSL to use ephemeral Diffie-Hellman EDH, we must set up the server- side SSL_CTX object properly. Providing DH parameters directly or, alternatively, a callback that returns the DH parameters accomplishes this goal. The function SSL_CTX_set_tmp_dh sets the DH parameters for a context, while the function SSL_CTX_set_tmp_dh_callback sets the callback. Since the callback mechanism subsumes the functionality of the former method, applications should provide only the callback. The callback function has the following signature: DH tmp_dh_callbackSSL ssl, int is_export, int keylength; The first argument to the callback is the SSL object representing the connection on which the parameters will be used. The second argument indicates whether an export-restricted cipher is being used; the argument value is nonzero, and zero otherwise. The main advantage of the callback is its ability to provide different functionality based on the third parameter, the key size. The DH parameters returned should have a key size equal to the last arguments value. Below, our server application is extended with a fully functional callback. The server application in its final form shows an implementation of this callback. Weve deferred discussion of the SSL option SSL_OP_SINGLE_DH_USE to this point. Some of the details from Chapter 8 will be helpful in understanding the impact of this option. Essentially, DH parameters are public information. A private key is generated and used for the key exchange from these parameters. Setting this option causes the server to generate a new private key for each new connection. In the end, setting this option provides better security at the cost of more computational power to make new connections. Unless there are special processor usage considerations, we should enable this option.

5.1.4.3 Cipher suite selection

122 A cipher suite is a set of algorithms that SSL uses to secure a connection. In order to make a suite, we need to provide algorithms for four functions: signingauthentication, key exchange, cryptographic hashing, and encryptingdecrypting. Keep in mind that some algorithms can serve multiple purposes. For example, RSA can be used for signing and for key exchange. OpenSSL implements a variety of algorithms and cipher suites when it comes to SSL connections. When designing secure applications, it is essential that algorithms having known security vulnerabilities not be allowed. The SSL_CTX_set_cipher_list function allows us to set the list of cipher suites that we authorize our SSL objects to use. The list of ciphers is specified by a specially formatted string. This string is a colon-delimited list of algorithms. Given the number of possible combinations, specifying all the acceptable ones explicitly would be quite cumbersome. OpenSSL allows for several keywords in the list, which are shortcuts for sets of ciphers. For instance, ALL is a shortcut for every available combination. Additionally, we can precede a keyword with the operator to remove all ciphers associated with the keyword from the list. Using this, we will create a string to define our custom cipher list. There are other operators such as + or -, but they are not essential for specifying a secure list. For applications that need a custom definition, the ciphers manpage is a good reference on string formation. SSL allows the use of anonymous ciphers. Anonymous ciphers allow the SSL connection to succeed without proper authentication of the peer by using the DH algorithm. In almost all circumstances, we want to block these ciphers; they are identified by the ADH keyword. In addition to suites that do not allow us to authenticate properly, we want to block low-security algorithms. The LOW keyword refers to ciphers that use a key of 64 bits or 56 bits without export crippling. Accordingly, the EXP keyword marks the ciphers that are export-crippled to 56 or 40 bits. Finally, we should block algorithms that have known weaknesses, e.g., MD5. We can also use the special keyword STRENGTH. Using this indicates that the list of cipher suites should be sorted by their strength their key size in order of highest to lowest. Employing this keyword causes our SSL connections to attempt to select the most secure suite possible, and if necessary, back off to the next most secure, and so on down the list. This keyword should be specified last on the list.

5.1.4.4 The final product