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

Andy Green andy at warmcat.com
Tue Apr 27 20:23:56 CEST 2021



On 4/27/21 6:05 PM, Catalin Raceanu wrote:
> 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.

OK, but it means boringssl is broken?  Or there's some other buildtime 
option in boringssl to make the new session cb arrive?

It sounds like something that should be fixed at boringssl, so it 
follows OpenSSL api promises, IIUI.

> 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;

Yes but again IIUI, this is just saying stuff depending on the tls lib 
apis doing what they should breaks if they don't.  It's correct, but the 
problem exists at the tls lib apis not doing what they should.

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

The thinking there was if the lib already acquired a session for that 
endpoint before the load request, it is already going to be newer than 
the one being loaded, it seems the right way.

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

I can't add new apis to v4.2-stable.

> 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?

If it's an issue in lws we have to pick a way to fix it, but these 
workarounds don't really solve it (because lws is not the root cause) 
just push the issue to user code to try to figure out what to do to get 
around it.

IIUI the right path is have a grep around on boringssl and see if 
there's something else to do at build or runtime to make the callback 
come, if no sign of a way through it then ask boringssl guys.

-Andy



More information about the Libwebsockets mailing list