Hi Satya,
Mbed TLS 2.19 is unsupported and has not received vulnerability fixes since its release over 4 years ago. We strongly recommend upgrading to a supported version:
Mbed TLS 2.28.x is stable and supported: the latest release was 2.28.7 a few weeks ago, and it will continue to receive security fixes until the end of the year. It will not be supported
past the end of this year, so if you plan to use Mbed TLS beyond 2024, I would not recommend moving to 2.28.
Mbed TLS 3.x will be supported with security fixes until around March 2027. I recommend upgrading to the latest release, 3.5.1 and then following the 3.6.x LTS release to continue
receiving security fixes.
WRT to the memory leak, it looks like if
tls_platform_setup_drbg() or mbedtls_ssl_setup () return an error, the function will return without deallocating the memory it allocated to mb_ctx, causing a memory leak.
Dave
From:
Satya Prakash Prasad <satyaprakash.developer.unix@gmail.com>
Date: Monday, 26 February 2024 at 09:48
To: Dave Rodgman <dave.rodgman@arm.com>
Cc: mbed-tls@lists.trustedfirmware.org <mbed-tls@lists.trustedfirmware.org>
Subject: Re: [mbed-tls] MBed TLS - Generic Question
Hi,
Please note that we are using the MBedTLS 2.19.1 release version since much development effort has been made using this version.
The issue we are facing currently is memory leaks. Let me explain in detail:
Please refer to the EAP peer code in HostAP stack: https://github.com/vanhoefm/hostap-wpa3/blob/master/eap_example/eap_example_peer.c
The main function is written here : https://github.com/vanhoefm/hostap-wpa3/blob/master/eap_example/eap_example.c
Since we need to connect multiple session we have modified the main function code from :
do {
printf("---[ server ]--------------------------------\n");
res_s = eap_example_server_step();
printf("---[ peer ]----------------------------------\n");
res_p = eap_example_peer_step();
} while (res_s || res_p);
to
do {
res_p = eap_example_peer_step();
if(eap_ctx.eapNoResp || eap_ctx.eapFail)
{
//On failure re-init is needed
eap_client_peer_deinit(); //On failure re-init is needed
eap_client_peer_init();
}
} while (1);
The rest are integrated as per the code referred in link above. The way MBedTLS is integrated in EAP stack is mentioned below:
EAP stack provides interfaces to different TLS / crypto stack like:
eap_example_peer_init() [https://github.com/vanhoefm/hostap-wpa3/blob/master/eap_example/eap_example_peer.c] -> eap_peer_sm_init()[https://github.com/vanhoefm/hostap-wpa3/blob/master/src/eap_peer/eap.c
]
->tls_init(&tls_config)->tls_init(const struct tls_config *conf)[https://github.com/vanhoefm/hostap-wpa3/blob/master/src/crypto/tls_openssl.c]
eap_example_peer_init() -> eap_peer_sm_init(()->tls_init(&tls_config)
We have replaced the openssl with MBedTLS code as like below:
void * tls_init(const struct tls_config *eap_conf)
int rc;
mbedtls_ssl_context *mb_ctx;
mb_ctx = hosteap_calloc(sizeof(*mb_ctx));
if (mb_ctx == NULL) {
return NULL;
}
mbedtls_ssl_init(mb_ctx);
mb_ctx->conf = &mbed_conf; // mbed_conf is a Global variable
mbedtls_ssl_config_init(&mbed_conf);
mbedtls_ssl_config_defaults(&mbed_conf, MBEDTLS_SSL_IS_CLIENT, MBEDTLS_SSL_TRANSPORT_STREAM, MBEDTLS_SSL_PRESET_DEFAULT);
mbedtls_ctr_drbg_init(&random); //random is global variable
rc = tls_platform_setup_drbg(&random);
if (rc) {
return null;
}
mbedtls_ssl_conf_rng(&mbed_conf, mbedtls_ctr_drbg_random, &random);
mbedtls_ssl_conf_export_keys_ext_cb(&mbed_conf, eap_tls_key_derivation, &eap_tls_keying );
if(mbedtls_ssl_setup(mb_ctx, &mbed_conf) != 0) {
return 0;
}
return mb_ctx;
}
Can anyone please confirm if the tls_init() method is correctly implemented?
Similarly with the EAP Host AP codebase we have changed the reference from OpenSSL to MBedTLs as like APIs defined in
https://github.com/vanhoefm/hostap-wpa3/blob/master/src/crypto/tls_none.c
I feel that somewhere in below code is causing memory leaks:
eap_client_peer_deinit(); //On failure re-init is needed
eap_client_peer_init();
The allocation and deallocation is not happening properly - somewhere in MbedTLs 2.19.1 stack allocated memory is not deallocated?
Any references or information would be an added advantage - we need your help to integrate MBedTLs in the EAP HostAP stack.
Thanks in advance.
Regards.
Prakash
On Mon, Jan 22, 2024 at 6:24 PM Dave Rodgman <dave.rodgman@arm.com> wrote:
Hi Satya,
We describe our policies for which branches are supported here:
https://github.com/Mbed-TLS/mbedtls/blob/development/BRANCHES.md
In short, I would recommend taking Mbed TLS 3.5.1, if you are able to use the 3.x series, or Mbed TLS 2.28.6 if you need to stay on the 2.28 LTS branch. Note that we plan to release Mbed TLS 3.6.0 LTS in late March / early April, which, as an LTS branch, will be supported for three years.
Dave
From: Satya Prakash Prasad via mbed-tls <mbed-tls@lists.trustedfirmware.org>
Date: Friday, 19 January 2024 at 06:08
To: mbed-tls@lists.trustedfirmware.org <mbed-tls@lists.trustedfirmware.org>
Subject: [mbed-tls] MBed TLS - Generic QuestionHi Team,
Referring to MBed release page - https://github.com/Mbed-TLS/mbedtls/releases?page=1 I see that there has been constant release periodically from Jul 27, 2018 mbedtls-2.1.14 till Nov 8, 2023 v3.5.1.
In the same context I understand that with each release there have been fixes and new features / enhancement implementation. There was a project that I was working in year 2020 were we tried to integrate MBed TLS in EAP https://github.com/prplfoundation/hostap. It was a practice exercise that our team did that time. I have not much idea as to which MBed TLS version was opted and integrated then.
Now that so many new releases are made after 2020 - are older versions can be taken as stable?
Is it that we should take the latest version and try again from scratch?
Thanks in advance.
Regards,
Prakash