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

Andy Green andy at warmcat.com
Fri Apr 30 06:46:19 CEST 2021

On 4/29/21 10:35 PM, Catalin Raceanu wrote:
> 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...

Yes I am just waiting for it to settle while still just in main, since 
the last change to the patch is like 12h ago, then it will be 
backported.  Despite the inevitability of only getting some bug reports 
just after a release, in fact there do seem to be multiple people 
building main on different platforms at any given time, as I know from 
bug reports sometimes within a few hours if I broke something there.

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

It will also be covered by checking at SSL close-time, although that 
might be later than desirable, boringssl can always be fixed too.

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

If it has already bailed if the same SESSION, then it's already doing 
what I was worrying about.


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

More information about the Libwebsockets mailing list