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

Catalin Raceanu cra at mega.nz
Thu Apr 29 23:35:05 CEST 2021

On 29.04.2021 22:39, Andy Green wrote:
> Thanks, I squashed them into your patch from yesterday and updated 
> main with it.

Any chance they will make it into 4.2-stable? There are no new public 
symbols... not sure if that is enough to qualify as binary compatible...

> 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

Right, that case is definitely covered. But for a longer lived session, 
if I understand correctly, the session info can be received even later 
than 500ms. Probably not worth complicating the code though, apparently 
it's far too rare.

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

Sorry, I didn't really understand the idea here.
My thoughts were for user code to provide a cb, that would be executed 
by "lws_tls_session_new_cb()" when given, just to let user code know 
when a new session had been added to cache, for {vhost, host, port}. It 
wouldn't need to check anything else, all necessary checks would have 
been already passed when execution reached that point.



More information about the Libwebsockets mailing list