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

Andy Green andy at warmcat.com
Wed Apr 28 18:52:05 CEST 2021

On 4/28/21 4:25 PM, Catalin Raceanu wrote:
> On 27.04.2021 22:09, andy at warmcat.com wrote:
>> that would also be improved if there was common code supporting a new lws sul in the cache entry struct, scheduled by handshake completion for eg +500ms, basically it's the stand-in for the async cb neither mbedtls nor boringssl provided.  I am not at my pc but IIRC we can query the SESSION from the SSL
> I've opened PR-2285 <https://github.com/warmcat/libwebsockets/pull/2285> 
> with a smaller change, because even though I think I correctly used the 
> `sul` schedule, I could not find a way to get the `SSL` from the 
> `SESSION` (only the latter is kept in a member of the tls structure).

I realize this isn't exactly simple to get an overview of, but the sul 
can live in struct lws_lws_tls that holds a pointer to the SSL.

> The PR only adds a synthetic cb, used only with boringssl, which so far 
> reported the received session as "resumable" every time. It can also be 
> improved later if it will prove to be insufficient.

I see that it gets you over your problem you have today, but it has a 
too narrow a focus on exactly your situation: the boringssl bug is 
allowed to contaminate ws-specific lws code, ie, as the patch is tls on 
raw or even http or h2 won't use this, nor will mbedtls.  Only ws 
protocol connections will act different for session cache on boringssl.

I modified it to provide the sul-related part and enable it also for 
mbedtls, and pushed it on _temp branch so you can test and iterate on it 
again to make sure it still does what you need.  I checked it passes 
ctest on my box for openssl with or without the sul stuff force-enabled 
and it builds for mbedtls, it will go through CI after it's merged.

It doesn't go near ws-specific code any more, there is a common point at 
lws_tls_client_connect() where all protocols using tls find out that the 
connection completed and have access to the wsi and SSL.  We don't have 
to care about nwsi when we handle a sul that is only scheduled when a 
tls connect() completed, that should be a wsi that is using tls directly.

It's more work to provide the complete solution but usually the results 
end up better for all the usecases by going the extra mile.


More information about the Libwebsockets mailing list