MBEDTLS_ERR_SSL_INTERNAL_ERROR while doing handshake on STM32 using coreHTTP with FreeRTOS

[AshvajitP]

Summary

I am trying to use mbedtls in coreHTTP with FreeRTOS on STM32F4 MCU with self-signed certificate from openssl I am getting an error MBEDTLS_ERR_SSL_INTERNAL_ERROR during TLS handshaking.

Changes done in TLS library :

• Added custom calloc and free from FreeRTOS (calloc was failing earlier)
• Changed string compare condition for PEM Certificate and key on NULL terminator
• Using SHA256 instead of SHA-512

More details on mBedtls integration on my FreeRTOS forum post : https://forums.freertos.org/t/integration-of-ssl-in-corehttp/19561 I have attached my mbedtls_config file for your reference.

System information

Mbed TLS version (number or commit id): Operating system and version: Configuration (if not default, please attach mbedtls_config.h): In attachments Compiler and options (if you used a pre-built binary, please indicate how you obtained it): IAR Additional environment information:

Expected behavior

Actual behavior

Steps to reproduce

Steps I have used to initialize HTTPS `int32_t returnStatus = pdTRUE; BaseType_t returnstat; typedef struct NetworkContext NetworkContext_t ; NetworkContext_t networkContext = {0}; TransportInterface_t transportInterface = {0}; TlsTransportParams_t xTlsTransportParams = { 0 }; networkContext.pParams = &xTlsTransportParams; NetworkCredentials_t xNetworkCredentials = { .pRootCa = Root_CA_cert, .rootCaSize = strlen(Root_CA_cert), .pClientCert = Client_cert, .clientCertSize = strlen(Client_cert), .pPrivateKey = Client_key, .privateKeySize = strlen(Client_key), }; transportInterface.pNetworkContext = &networkContext; transportInterface.recv = TLS_FreeRTOS_recv; transportInterface.send = TLS_FreeRTOS_send;

while( pdPASS != connectToServer(&networkContext,HOST_NAME, HTTPS_PORT, &xNetworkCredentials) ) { vTaskDelay( pdMS_TO_TICKS( 5000U ) ); }`

int32_t connectToServer(NetworkContext_t *pNetworkContext, const char *host, const unsigned int port,NetworkCredentials_t* xNetworkCredentials) { BaseType_t xStatus = 0; FreeHeapSize_t = xPortGetFreeHeapSize(); xStatus = TLS_FreeRTOS_Connect(pNetworkContext,host,port, xNetworkCredentials, TRANSPORT_SEND_RECV_TIMEOUT_MS,TRANSPORT_SEND_RECV_TIMEOUT_MS); if(xStatus != 0) { return pdFAIL; } else { return pdPASS; } }

Additional information

mbedtls_config.txt Http_Open_source.txt Http_Open_header.txt

[paul-elliott-arm]

Hi,

Given your modification of the code and it being on an unsupported platform, I really don't think I can help you here. The mailing list (mbed-tls@lists.trustedfirmware.org) may be of more help, but I would doubt it given again, your code and platform is pretty unique. Some hints on porting to bare metal can be found here : https://mbed-tls.readthedocs.io/en/latest/kb/how-to/how-do-i-port-mbed-tls-to-a-new-environment-OS/

The only thing I can suggest is attaching a debugger and determining where the MBEDTLS_ERR_SSL_INTERNAL_ERROR is being returned, which might show at least what has not been initialised or what has failed, as there could be any number of causes of this, from what you have provided there is no way I could determine that.

[AshvajitP]

Hi Paul, Thanks for your reply, I am getting this error from https://github.com/Mbed-TLS/mbedtls/blob/development/library/ssl_tls.c#L4545 from ssl_tls.c at the last step when I am trying to do a handshake. I have attached my mbedtls_config file, if #I am misisng any configuration for this.

[paul-elliott-arm]

Ok.

First point, that line number does not return that error code, it calls mbedtls_ssl_handshake_client_step(), which really does not narrow things down at all.

I have seen your config, the problem here is that you are asking me to debug your code, which is something we are generally not going to do, and certainly not on an unsupported setup with modified code which we don't even have access to. That error code should not occur under normal situations, that either means you have not intialised something properly (unlikely) or some of your porting modifications are wrong (more likely).

If you have a reproducable bug on a supported system with a small reproducer, then please by all means open another ticket.