Topic: TLS session cache thread safety
The client application I am working on requires a different cache-handling model than what is expected in wolfSSL. Instead of having a single application-wide cache, I need to store the sessions per-server.
Originally, I was thinking about disabling the internal cache and using external cache (HAVE_EXT_CACHE). However, this would likely require to use a custom allocator, and/or I would probably need to be touching wolfSSL internals, at least for making a deep copy of WOLFSSL_SESSION.
Then I thought about still using the internal cache (but likely reducing its size), mainly to take care of the allocations, and keeping my per-server cache next to it. (Storing the sessions as byte buffers and using wolfSSL_i2d_SSL_SESSION and wolfSSL_d2i_SSL_SESSION for conversion.)
When examining these options, I ran into the question of the session cache being thread-safe. At the lowest level, it is protected by session_mutex, so the cache itself should remain consistent. However, I am not so sure about the sessions. E.g. when I use wolfSSL_get1_session, I obtain a pointer to a structure in the session cache, but I cannot see what is preventing the session structure in the cache from being updated (replaced with another session) while I am working with it.
Since the session cache can be updated e.g. after TLS handshake performed on unrelated WOLFSSL, I can't see an easy way of adding external locking without resorting to something like a global mutex.
Am I missing something, or is this a limitation of the session cache?