Ephemeral keying Step 3: SSL Options and Cipher Suites

120 Additionally, we need to delve into the selection of cipher suites. A cipher suite is a combination of lower-level algorithms that an SSL connection uses to do authentication, key exchange, and stream encryption. Suite selection is important because OpenSSL supports some algorithms for compatibility that we want to exclude for security reasons. Similarly, some of the cipher suites that are secure require an application to provide callbacks in order to be utilized. Learning how to do these things properly and extending our example for this final step will be the topic of this section.

5.1.4.1 Setting SSL options

The SSL_CTX_set_options function provides the developer with finer-grained control over the SSL connections spawned from the context. Using this function, we can enable the bug workarounds built into the OpenSSL library. For instance, a particular version of a Netscape product Netscape-Commerce 1.12 will truncate the material used for key generation. In order for our SSL programs to establish a connection to a peer with such a bug, we need to enable the workaround. These fixes are useful only to programs that will communicate with a peer known to have bugs, but enabling the workarounds does not hurt anything as a rule. These bug fixes can be enabled individually, but instead we should set the SSL_OP_ALL flag, which will enable all of the workaround code. Like the function SSL_CTX_set_verify , the second parameter to this function is a set of flags. Again, the flags can be combined with the logical OR operation. An important fact about this call is that once an option is set, it cant be cleared: this function only adds the options presented by the second argument to the options set contained in the SSL_CTX object. The new set of options is returned by this function. In addition to the workarounds for buggy SSL peers, this function allows us to tighten the security of our SSL connections. By setting the option SSL_OP_NO_SSLv2 , we prevent the SSLv2 protocol from being used. As we noted in Step 1, this is a very useful feature. Using this option, we can create an SSL_CTX object based on the compatibility method, SSLv23_method , and the context will not allow SSLv2 peers. This is useful since electing to base our context upon either SSLv3_method or TLSv1_method would prevent the other from connecting correctly. Two server-side-only options that bear consideration are SSL_OP_EPHEMERAL_RSA and SSL_OP_SINGLE_DH_USE . The former causes our context object to attempt to use a temporary RSA key for the key exchange. The details of this process are discussed below, but generally, this option should never be used, since it violates the SSLTLS protocol specification. We discuss the SSL_OP_SINGLE_DH_USE flag in the next section.

5.1.4.2 Ephemeral keying

In our examples thus far, both the server and the client certificates have been based on RSA key pairs. Because the RSA algorithm can be used for most signing and encrypting, SSL uses it to perform the key agreement necessary to create the shared key under which the data in the stream is encrypted. This technique, such as when the key exchange is conducted through a persistent key, is called static keying. Building on this definition, ephemeral keying is defined as key exchange through a temporary key. At first, it may seem that temporary keys may not allow for proper authentication—not true. Generally, with ephemeral keying, the authentication is accomplished through signature verification with persistent keys, and the temporary keys are used only for key agreement. There are two main advantages of ephemeral keying over static keying from a security perspective. Weve said that our example uses RSA keys in the certificates, but consider a case in which the certificates are based upon DSA keys. The DSA algorithm provides a mechanism for signing but not for encrypting. Thus, having only DSA keys on either side of an SSL connection leaves the 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