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

andy at warmcat.com andy at warmcat.com
Tue Apr 27 21:09:06 CEST 2021



On April 27, 2021 6:39:17 PM UTC, Catalin Raceanu <cra at mega.nz> wrote:
>
>On 27.04.2021 21:23, Andy Green wrote:
>>
>> OK, but it means boringssl is broken?
>
>
>Yes, this is my understanding so far.
>
>
>> It sounds like something that should be fixed at boringssl, so it 
>> follows OpenSSL api promises, IIUI.
>
>
>True again, it should be fixed at boringssl.
>
>
>>>      - LWS is not notified about the new session, and the old one is
>
>>> not replaced in cache;
>>
>> this is just saying stuff depending on the tls lib apis doing what 
>> they should
>
>
>Absolutely. The scenario was only given as example, to easily
>understand 
>the problem, not to say that LWS is doing anything wrong.
>
>
>There's nothing wrong with LWS, and a workaround would definitely _not_
>
>solve it. However it would be quick to overcome it (until the problem
>is 
>identified in boringssl, then fixed, then webrtc would pick it up, then
>
>the implementation here would upgrade the webrtc version...).
>
>If a code change for LWS that would help with this is not appropriate 
>(i.e. proposal 2 could make sense with or without this problem, but
>it's 
>too late for 4.2-stable), do you have any advice for mitigating this at
>
>LWS level or user code level?

There is the mbedtls case that doesn't provide the callback; openssl apis recognize the session message is asynchronous and handles it well with an async cb, while mbedtls doesn't provide any of that.  Atm mbedtls version of this samples the session at a fixed event in the connection flow later, the session message may or may not have arrived at the client.  So that's not great for this either.

But considering mbedtls case, 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, we can update the cache entry if that fires.  And we can do the same when closing / destroying the SSL.  (Remember to lws_sul_cancel() the new sul when the SSL is being destroyed).

If that actually matches what's possible, then you can build those common pieces if LWS_WITH_MBEDTLS or ...BORINGSSL all in private structs and code without needing any public abi or new cmake option changes.  You wouldn't build the new sul stuff for default openssl case.  But the new session cache update on close SSL could be active for all cases.

If later boringssl is fixed, it should be ok to get the synthetic cb and the real one, we just update the cached session twice.

-Andy

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


More information about the Libwebsockets mailing list