gilles-peskine-arm
commented
1 year ago I've noticed that some times the preceeding handshake's error code is -17168 (-0x4310), which I've tried to find the represented meaning, but failed to
Use programs/util/strerror to see the error message corresponding to a numerical value. The values don't depend on the architecture or on the compile-time configuration, so you can build a copy of the library in the default configuration on your development machine for this program.
mbedtls-strerror -0x4310
Last error was: -0x4310 - RSA - The private key operation failed : BIGNUM - Memory allocation failedSo something is leaking memory.
The memory leak is probably the cause of the signature verification failure, not a consequence. Although I am a bit surprised that the error is consistently MBEDTLS_ERR_RSA_VERIFY_FAILED: looking at our RSA code, it never returns this exact error for out-of-memory. So I suspect that there's an uncaught malloc failure somewhere else which leads to an invalid key object or invalid buffer content at some point.
HamzaHajeir
Summary
System information
Mbed TLS version (number or commit id): 2.28.3 Operating system and version: Built with Ubuntu Configuration (if not default, please attach
mbedtls_config.h): Please find attached config.txtCompiler and options (if you used a pre-built binary, please indicate how you obtained it): With default esp-idf compilation environment: version
release/v4.4Additional environment information: Built using a fork of espressif/esp32-arduino-lib-builder
Expected behavior
I host TLS webserver using LwIP ALTCP TLS - MBEDTLS port, I expect every client (browser) to be able to connect anytime.
In essence, It works correctly to some point, correct behaviour includes making successful handshakes and communication. The problem starts after some amount of time/process, in which causes to deny any new connections, even from browsers were already connected by the means of a reload button.
Already connected connections prior to this point continue to communicate successfully afterwards.
The error code returned by the
mbedtls_ssl_handshakeis fixed at -17280 (-0x4380) (MBEDTLS_ERR_RSA_VERIFY_FAILED).I've noticed that some times the preceeding handshake's error code is -17168 (-0x4310), which I've tried to find the represented meaning, but failed to, nearest assumption is
MBEDTLS_ERR_RSA_PRIVATE_FAILED | MBEDTLS_ERR_MPI_NEGATIVE_VALUE.Is there any hint for what's going wrong? With thanks,
Actual behavior
Log shows:
Or in the other described case:
Steps to reproduce
It's hard to tell how to reproduce, as the time is uncertain, and upon that any further reset of the webserver (including SSL context) yield in yet again successful handshakes until it reappears.
However, here's the running ALTCP MBEDTLS Code, pointing to the handshake API call:
https://github.com/HamzaHajeir/esp-lwip/blob/2.1.2-esp-patch/src/apps/altcp_tls/altcp_tls_mbedtls.c#L278
Additional information
Meanwhile this issue, the MCU is able to reconnect to a MQTT server by TLS with successful (one-way auth) handshakes,
My investigation of a very long log shows that this problem leaks memory too.
Debug Logs.