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

Andy Green andy at warmcat.com
Thu Apr 29 21:39:47 CEST 2021

On 4/29/21 1:43 PM, Catalin Raceanu wrote:
> On 28.04.2021 19:52, Andy Green wrote:
>> the sul can live in struct lws_lws_tls that holds a pointer to the SSL.
>> I modified it to provide the sul-related part and enable it also for 
>> mbedtls
> Thank you! I don't know if would have eventually found `lws_lws_tls`.
>> and pushed it on _temp branch so you can test and iterate on it again 
>> to make sure it still does what you need.
> Looks very good, and it does add new sessions to cache. I've added a few 
> minor changes in github _temp 
> <https://github.com/catalinr-m/libwebsockets/commits/_temp_synth_cb>, 
> the last 2 commits.
> There are 2 removed lines of code, that are not related to this:
> - removed "wsi->tls_session_reused = 1;" because now it's only used for 
> mbedtls;
> - removed "lws_sul_cancel(&ts->sul_ttl);" because it was also done in 
> "__lws_tls_session_destroy(ts);" which was called 3 lines later.

Thanks, I squashed them into your patch from yesterday and updated main 
with it.  (There were some other issues shown up by CI around Wolfssl 
not supporting setting the SESSION time api and the type of setting the 
time differing between openssl variants.)

> I wonder if it's worth for "lws_sess_cache_synth_cb()" to re-schedule 
> itself if the session was invalid when it was executed.

If we are doing the synthetic cb, I added a call to it at the time we're 
closing the SSL, to update the cache with any SESSION it had ended up 
with right at the end.  This also covers the case the tls link was 
shorter-lived than the 500ms we're using for the scheduled check.  I 
tried it again with the ctest set here and that was still OK.

> Also, for a future LWS version and if it proves to be useful, would it 
> be appropriate to add a user callback, that would get called by 
> "lws_tls_session_new_cb()", after a new session has been successfully 
> added to cache (i.e. passing the vhost name, host name and port)?

I think it won't be unusual just calling the cache update cb will find 
it's the same SESSION it already had.  So you'd need to check if 
anything actually changed before calling the cb.

There's a system ops struct "lws_system" that is probably good for 
interfacing to the user cb, it's for wiring up system / platform user 
code to system level events that don't really have a specific object 
they belong to.


> Regards,
> Catalin
> _______________________________________________
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
> https://libwebsockets.org/mailman/listinfo/libwebsockets

More information about the Libwebsockets mailing list