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.
_______________________________________________
Hostap mailing list
Hostap@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/hostap
