Observed behavior

After opening and closing many ssl sessions, mbedtls_ssl_handshake() eventually ends up beeing stuck at some point. This happens while using esp-idf example code for tls as well as with WiFiClientSecure in the esp32-arduino environment.

Expected behavior

If something goes wrong during mbedtls_ssl_handshake() we expect an error code to be returned in order to safely proceed without having a stuck task. At the very least it should timeout somehow.

Steps to reproduce

This is not easy to reproduce. In our case we have some https connection every minute or so and some high priority tasks that run on the same core (both pinned ad CPU1) . After a day or so we only see output from other tasks in the console and the https task is stuck during handshake:

[I][ssl_client.cpp:45] start_ssl_client(): Free heap before TLS 208096
[I][ssl_client.cpp:47] start_ssl_client(): Starting socket
[I][ssl_client.cpp:75] start_ssl_client(): Seeding the random number generator
[I][ssl_client.cpp:84] start_ssl_client(): Setting up the SSL/TLS structure...
[I][ssl_client.cpp:97] start_ssl_client(): Loading CA cert
[I][ssl_client.cpp:153] start_ssl_client(): Performing the SSL/TLS handshake...

this is from the arduino lib which looks like:

    while ((ret = mbedtls_ssl_handshake(&ssl_client->ssl_ctx)) != 0) {
        if (ret != MBEDTLS_ERR_SSL_WANT_READ && ret != MBEDTLS_ERR_SSL_WANT_WRITE) {
            return handle_error(ret);
        }
    }

@copercini can confirm that it is indeed not the while loop which is stuck but rather the mbedtls_ssl_handshake() itself.
This seems to be a know issue on FreeRTOS even on the ESP8266, especially when there are tasks present with higher priority (see SuperHouse/esp-open-rtos#182).