[Libwebsockets] TLS session cache and reuse, lws_tls_session_new_cb() not executed by BoringSSL

Catalin Raceanu cra at mega.nz
Tue Apr 27 19:05:06 CEST 2021


Hello,

Caching and reusing TLS sessions for OpenSSL uses 
lws_tls_session_new_cb() set with SSL_CTX_sess_set_new_cb()
for noticing when a new session has been negociated.
Unfortunately a more recent BoringSSL version (for reference: the one 
used by the latest versions of WebRTC)
is not executing that callback, despite it being correctly set by LWS.
The consequence of this is that a new session is not added to the LWS 
session cache.

This can be worked around in user code, by retrieving the new session in 
the lws_callback_function set in lws_protocols,
for reason LWS_CALLBACK_CLIENT_ESTABLISHED, and add it to the cache 
there, using lws_tls_session_dump_load().
This works fine the first time, but will not replace an old session 
already present in the cache.

     Consider the following scenario:
     - app starts;
     - an old serialized session is loaded into LWS cache;
     - LWS attempts to reuse it for a new connection;
     - the remote server rejcts the old session and negociates a new one;
     - LWS is not notified about the new session, and the old one is not 
replaced in cache;
     - the workaround kicks in, gets the new session, but the old one is 
already present in the cache,
       for the same tag, and will not be replaced.


A few alternative options for fully working around the limitation in 
this case:

1) Change lws_tls_session_dump_load() to always replace the session in 
cache (do what lws_tls_session_new_cb() does
    now).
    The original idea appeared to be correct, of not replacing sessions 
in cache with newly loaded ones,
    but unfortunately there is no way to force loading a session into cache.

2) Add a new function to drop a session from cache, based on its tag. 
This is probably the simplest one.

3) Add a new compile-time symbol, that could be used to wrap the code in 
lws_tls_session_dump_load() that checks
    for a session being already present in cache.

4) Add an extra argument to lws_tls_session_dump_load(), based on which 
it would force replacing a session into cache.

Do any of these sound reasonable?

Regards,
Catalin



More information about the Libwebsockets mailing list