[PATCH] Implement new functions for EAP:

[Juliusz Sosinowicz]

Hi Jouni,

thank you for your feedback. We are aware of the issue with TLS 1.3 in 
wpa_supplicant with wolfSSL. We have put in work to fix this and I am 
preparing another patch that will add TLS 1.3 support along with a few 
other new features when using wolfSSL as the crypto/TLS backend.

This memory leak hasn't been reported before. I will fix it and include 
it in the upcoming patch.

Sincerely
Juliusz Sosinowicz

On 18/04/2022 16:09, Jouni Malinen wrote:
> On Thu, Aug 26, 2021 at 11:25:34AM +0200, Juliusz Sosinowicz wrote:
>> - `tls_get_tls_unique`
>> - `tls_connection_get_cipher_suite`
>> - `tls_connection_get_peer_subject`
>> - `tls_connection_get_own_cert_used`
>>
>> The necessary wolfSSL changes are located in https://github.com/wolfSSL/wolfssl/pull/4205 .
> Thanks, applied with some cleanup in a number of separate commits.
>
> While testing these with various wolfSSL versions, I noticed that there
> were some regressions or old issues being revealed by additional
> functionality getting enabled. I fixed some of these, but it looks like
> there is still something wrong going on whenever TLS 1.3 is enabled and
> the wpa_supplicant mechanism of disabling that by default not working
> with wolfSSL. I ended up doing most of the testing with --disable-tls13
> build of wolfSSL to verify previously working functionality.
>
> As far as the now enabled TLS session resumption and caching is
> concerned, it looks looks like there might be a memory leak in the
> WOLFSSL_SESSION ex_data handling. tls_connection_set_success_data() adds
> a heap allocated memory pointer with wolfSSL_SESSION_set_ex_data() and
> that buffer is not always cleared. It looks like remove_session_cb() is
> supposed to do that, but there is no mechanism to force that to happen
> when exiting the process. It looks like there is
> wolfSSL_flush_sessions(), but that is not called and even it it were,
> the current implementation of it does not really do anything. I'm not
> sure whether this is a real memory leak in the sense of each session
> leaking one instance or whether this just shows up since the session
> entry has not timed out and it would have been freed when processing the
> eventual timeout.
>