4

I'm making changes to a client-side SSL application in order to support TLSv1.3. In order to support session reuse, I'm calling SSL_CTX_sess_set_new_cb to register a callback that OpenSSL calls whenever it has negotiated a new session with the server. In this callback, my application saves the session in the application's session cache so that the session can be reused in a later connection.

However, OpenSSL calls my callback only if OpenSSL's internal client-side session cache is enabled [1]. This is accomplished via:

SSL_CTX_set_session_cache_mode(sslContext, SSL_SESS_CACHE_CLIENT);

But now there is a problem that there are now two session caches duplicating the same sessions: my application's “external” cache and OpenSSL's internal cache. It would be nice to eliminate this duplication, but both caches are needed. The internal cache is needed to enable my callback function (as according to OpenSSL's limitation), and the external cache is needed because it's the only way my application can look up a session and reuse it via the SSL_set_session function. Indeed, this seems like a universal problem when using the internal cache. According to the man page for SSL_CTX_set_session_cache_mode, under the section for SSL_SESS_CACHE_CLIENT [2]:

As there is no reliable way for the OpenSSL library to know whether a session should be reused or which session to choose (due to the abstract BIO layer the SSL engine does not have details about the connection), the application must select the session to be reused by using the SSL_set_session(3) function.

As I understand it, this means:

  • Client-side applications must do the work to provide the SSL_SESSION* to OpenSSL to reuse a session. I.e., OpenSSL cannot decide whether to reuse a client-side session on its own—even if the session exists in its internal cache.
  • Thus, that pointer must come from some external cache or store—not the internal client-side session cache.

This leaves me wondering what's a legitimate use case for enabling the internal client-side session cache other than as a means for enabling the session callback. For example, are there cases where it makes sense to enable the internal cache but not have an external cache or store? Is there a case where it makes sense to enable the internal cache when not using the session callback function? To be clear, I'm talking only about client-side applications.

[1] https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_sess_set_new_cb.html

[2] https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_session_cache_mode.html

Craig M. Brandenburg
  • 3,354
  • 5
  • 25
  • 37

1 Answers1

3

It is not correct that the internal cache is required in order for you to have external caching. You can have just the external cache if you wish using the SSL_SESS_CACHE_NO_INTERNAL_STORE option:

SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_CLIENT | SSL_SESS_CACHE_NO_INTERNAL_STORE);

See the documentation here: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_session_cache_mode.html

It is possible to gain access to the internal cache using the function SSL_CTX_sessions. See:

https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_sessions.html

This gives you the session cache in the form of an LHASH_OF(SSL_SESSION) which you could then search using the various LHASH functions (e.g. lh_SSL_SESSION_doall). See:

https://www.openssl.org/docs/man1.1.1/man3/lh_TYPE_doall.html

So, if your caching needs are quite simple then the internal cache might be sufficient.

Matt Caswell
  • 8,167
  • 25
  • 28
  • Thanks. Looks like `SSL_SESS_CACHE_NO_INTERNAL_STORE` is what I want. My application needs its external cache because the hash function is based on connection-specific properties that are relevant for deciding whether to reuse a session, whereas the internal hash function is based only the session id. – Craig M. Brandenburg Feb 12 '21 at 03:22