Server-side SSL sessions SSL Session Caching

127 To reuse a saved session, we need to call SSL_set_session before calling SSL_connect . The reference count of the SSL_SESSION object will be incremented automatically so we should follow the call with SSL_SESSION_free . After reusing a session, it is a good idea to call SSL_get1_session before disconnecting to replace the SSL_SESSION object that weve cached. The reason is that renegotiations may occur during the connection. Renegotiations cause the creation of a new SSL_SESSION , so we should keep only the most recent renegotiation is discussed in more detail later. Now that we understand the basics of enabling session caching, well take a brief look at incorporating it into a client application. Example 5-13 shows pseudocode for our client-side session caching. Now that weve established an implementation for a client, well elaborate upon some of the details of session caching as we explore the implementation necessary for server-side caching. Example 5-13. Pseudocode for client-side caching ssl = SSL_newctx ... setup underlying communications layer for ssl ... ... connect to host:port ... if saved session for host:port in cache SSL_set_sessionssl, saved session SSL_SESSION_freesaved session SSL_connectssl call post_connection_checkssl, host and check return value ... normal application code here ... saved session = SSL_get1_sessionssl if saved session = NULL enter saved session into cache under host:port SSL_shutdownssl SSL_freessl

5.2.1.2 Server-side SSL sessions

All sessions must have a session ID context. For the server, session caching is disabled by default unless a call to SSL_CTX_set_session_id_context is made. The purpose of the session ID context is to make sure the session is being 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. Along the same lines, we can use session ID contexts to exercise a finer-grained control over sessions within our application. For example, authenticated clients could have a different session ID context than unauthenticated ones. The context itself can be any data we choose. We set the context through a call to the above function, passing in our context data as the second argument and its length as the third. After setting the session ID context, session caching is enabled on the server side; however, it isnt configured completely yet. Sessions have a limited lifetime. The default value for session timeout with OpenSSL is 300 seconds. If we want to change this lifetime, a call to SSL_CTX_set_timeout is necessary. Although the default server automatically flushes expired sessions, we may still want to call SSL_CTX_flush_sessions manually, e.g., when we disable automatic session flushing. One important function that allows us to tweak the behavior of a server with respect to caching is SSL_CTX_set_session_cache_mode . Like several other mode-setting calls in OpenSSL, the mode is set using flags that are joined by a logical OR operation. One such flag is SSL_SESS_CACHE_NO_AUTO_CLEAR . This disables the automatic flushing of expired sessions. It is useful for servers with tighter processor usage constraints. The automatic behavior can cause unexpected delays; thus, disabling it and manually calling the flush routine when free cycles are 128 available can improve performance. Another flag that can be set is SSL_SESS_CACHE_NO_INTERNAL_LOOKUP . Up to this point, weve relied solely on the internal lookup, but in the next section, well outline an on-disk caching method that can replace the internal lookup methods. Session caching adds subtleties when we also use connection renegotiations. Before implementing a caching server, we should be aware of the potential pitfalls. The section below on renegotiation explores some of these problems after explaining a little more about what renegotiation entails.

5.2.1.3 An on-disk, session caching framework