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.
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.
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:
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.
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.
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.