9.3 Using Session Caching to Make SSL Servers More Efficient

9.3.1 Problem

You have a client and server pair that speak SSL to each other. The same client often makes several connections to the same server in a short period of time. You need a way to speed up the process of the client's reconnecting to the server without sacrificing security.

9.3.2 Solution

The terms SSL session and SSL connection are often confused or used interchangeably, but they are, in fact, two different things. An SSL session refers to the set of parameters and encryption keys created by performing an SSL handshake. An SSL connection is an active conversation between two peers that uses an SSL session. Normally, when an SSL connection is established, the handshake process negotiates the parameters that become a session. It is this negotiation that causes establishment of SSL connections to be such an expensive operation.

Luckily, it is possible to cache sessions. Once a client has connected to the server and successfully completed the normal handshake process, both the client and the server can save the session parameters so that the next time the client connects to the server, it can simply reuse the session, thus avoiding the overhead of negotiating new parameters and encryption keys.

9.3.3 Discussion

Session caching is normally not enabled by default, but enabling it is a relatively painless process. OpenSSL does most of the work for you, although you can override much of the default behavior (for example, you might build your own caching mechanism on the server side). By default, OpenSSL uses an in-memory session cache, but if you will be caching a large number of sessions, or if you want sessions to persist across boots, you may be better off using some kind of disk-based cache.

Most of the work required to enable session caching has to be done on the server side, but there's not all that much that needs to be done:

1. Set a session ID context. The purpose of the session ID context is to make sure the session is reused for the same purpose for which it was created. For instance, a session created for an SSL web server should not be automatically allowed for an SSL FTP server. A session ID context can be any arbitrary binary data up to 32 bytes in length. There are no requirements for what the data should be, other than that it should be unique for the purpose your server serves you don't want to find your server getting sessions from other servers.

2. Set a session timeout. The OpenSSL default is 300 seconds, which is probably a reasonable default for most applications. When a session times out, it is not immediately purged from the server's cache, but it will not be accepted when presented by the client. If a client attempts to use an expired session, the server will remove it from its cache.

3. Set a caching mode. OpenSSL supports a number of possible mode options, specified as a bit mask:

   SSL_SESS_CACHE_OFF

   Setting this mode disables session caching altogether. If you want to disable session caching, you should specify this flag by itself; you do not need to set a session ID context or a timeout.

   SSL_SESS_CACHE_SERVER

   Setting this mode causes sessions that are generated by the server to be cached. This is the default mode and should be included whenever you're setting any of the other flags described here, except for SSL_SESS_CACHE_OFF.

   SSL_SESS_CACHE_NO_AUTO_CLEAR

   By default, the session cache is checked for expired entries once for every 255 connections that are established. Sometimes this can cause an undesirable delay, so it may be desirable to disable this automatic flushing of the cache. If you set this mode, you should make sure that you periodically call SSL_CTX_flush_sessions( ) yourself.

   SSL_SESS_CACHE_NO_INTERNAL_LOOKUP

   If you want to replace OpenSSL's internal caching mechanism with one of your own devising, you should set this mode. We do not include a recipe that demonstrates the use of this flag in the book, but you can find one on the book's companion web site.

You can use the following convenience function to enable session caching on the server side. If you want to use it with the SSL server functions presented in Recipe 9.2, you should create an SSL_CTX object using spc_create_sslctx( ) yourself. Then call spc_enable_sessions( ) using that SSL_CTX object, and pass the SSL_CTX object to spc_accept( ) so that a new one will not be created automatically for you. Whether you enable session caching or not, it's a good idea to create your own SSL_CTX object before calling spc_accept( ) anyway, so that a fresh SSL_CTX object isn't created for each and every client connection.

#include <openssl/bio.h> #include <openssl/ssl.h>     void spc_enable_sessions(SSL_CTX *ctx, unsigned char *id, unsigned int id_len,                          long timeout, int mode) {   SSL_CTX_set_session_id_context(ctx, id, id_len);   SSL_CTX_set_timeout(ctx, timeout);   SSL_CTX_set_session_cache_mode(ctx, mode); }

Enabling session caching on the client side is even easier than it is on the server side. All that's required is setting the SSL_SESSION object in the SSL_CTX object before actually establishing the connection. The following function, spc_reconnect( ), is a re-implementation of spc_connect_ssl( ) with the necessary changes to enable client-side session caching.

BIO *spc_reconnect(char *host, int port, SSL_SESSION *session,                    spc_x509store_t *spc_store, SSL_CTX **ctx) {   BIO *conn = 0;   int our_ctx = 0;   SSL *ssl_ptr;       if (*ctx) {     CRYPTO_add(&((*ctx)->references), 1, CRYPTO_LOCK_SSL_CTX);     if (spc_store && spc_store != SSL_CTX_get_app_data(*ctx)) {       SSL_CTX_set_cert_store(*ctx, spc_create_x509store(spc_store));       SSL_CTX_set_app_data(*ctx, spc_store);     }   } else {     *ctx = spc_create_sslctx(spc_store);     our_ctx = 1;   }       if (!(conn = BIO_new_ssl_connect(*ctx))) goto error_exit;   BIO_set_conn_hostname(conn, host);   BIO_set_conn_int_port(conn, &port);       if (session) {     BIO_get_ssl(conn, &ssl_ptr);     SSL_set_session(ssl_ptr, session);   }   if (BIO_do_connect(conn) <= 0) goto error_exit;   if (!our_ctx) SSL_CTX_free(*ctx);   if (session) SSL_SESSION_free(session);   return conn;     error_exit:   if (conn) BIO_free_all(conn);   if (*ctx) SSL_CTX_free(*ctx);   if (our_ctx) *ctx = 0;   return 0; }

Establishing an SSL connection as a client may be as simple as setting the SSL_SESSION object in the SSL_CTX object, but where does this mysterious SSL_SESSION come from? When a connection is established, OpenSSL creates an SSL session object and tucks it away in the SSL object that is normally hidden away in the BIO object that is returned by spc_connect_ssl( ). You can retrieve it by calling spc_getsession( ).

SSL_SESSION *spc_getsession(BIO *conn) {   SSL *ssl_ptr;       BIO_get_ssl(conn, &ssl_ptr);   if (!ssl_ptr) return 0;   return SSL_get1_session(ssl_ptr); }

The SSL_SESSION object that is returned by spc_getsession( ) has its reference count incremented, so you must be sure to call SSL_SESSION_free( ) at some point to release the reference. You can obtain the SSL_SESSION object as soon as you've successfully established a connection, but because the value can change between the time the connection is first established and the time it's terminated due to renegotiation, you should always get the SSL_SESSION object just before the connection is terminated. That way, you can be sure you have the most recent session object.

9.3.4 See Also

Recipe 9.2