Hello mbedtls mailing list,
I'm working to modify mbedTLS (3.6.2) to use our PSA Crypto Implementation in a separate library. Our solution does not make use of PSA 'drivers' that mbedTLS refers to. I've modified makefiles to not build PSA Crypto files, and have enabled MBEDTLS_PSA_CRYPTO_C & MBEDTLS_USE_PSA_CRYPTO. I've also defined MBEDTLS_PSA_ACCEL_ALG_XXX for our supported algorithms.
1. Is there a good way to determine whether a given TLS/X509 configuration would require a certain 'legacy' (maybe a better term is 'non-PSA') crypto file to be built into the mbedTLS library?
* The goal is to build as few crypto source files into the mbedTLS source files as possible, maximizing usage of our separate PSA implementation
2. Example: My test application using mbedtls_x509_crt_parse() receives linking errors for mbedtls_ecp_(group/point)_xxx() and mbedtls_mpi_xxx() that are referenced in pkparse.c (which I am building into the library).
* Ecp.c is currently excluded from the build (as is its define) - if I add it, I add significantly more linking errors for mbedtls_mpi APIs. I was under the impression that ECP and MPI APIs could be avoided with the correct configuration.
* If ecp/mpi helper APIs are needed still for x509, this would be good to know. However, I'd like to avoid usage of MPI APIs that perform actual software calculations.
See the screenshot for a list of non-PSA crypto files I am currently building to test with. I imagine I may have to add more incrementally.
[cid:image001.png@01DB726D.879014D0]
Any insights on this general use case or my ECP troubles with x509 would be appreciated. I plan to extend the strategy as these are the findings from an attempt to use just one x509 API.
Best,
Kevin Zak
Hello,
I recently updated mbedTLS library version 2.6.2 to 3.6.2. I am using the
library to add https to Mongoose web server on a STM32H753 with FreeRTOS +
LWIP.
2.6.2 was generated in a IAR project using STMCubeMX.
What I am noticing is that file transfer performance has gotten much worse.
With version 2.6.2 it took a few minutes to transfer a file of around 33
MB, now with version 3.6.2 it takes around 15 min. What could this depend
on? Attached is the configuration used for the two versions. The
certificate for https is EC curve secp256r1.
Thank you
Dear Developer,
I was reviewing the code and noticed that in the TLS 1.3 handshake protocol state machine, the "Change Cipher Spec" state has been divided into five different states based on its occurrence timing. Could you please clarify if there are any specific considerations for this approach?
Additionally, these states can appear multiple times during a single handshake, which implies multiple "Change Cipher Spec" messages. However, the TLS 1.3 standard suggests that the "Change Cipher Spec" should only appear once in a single handshake. Could you kindly explain the rationale behind this design decision?
Thank you for your time and assistance. I look forward to your response.
Best regards,
XiangDong Li
Hello,
I am currently working on a project using STM32CubeIDE, where I am leveraging mbedTLS v2.16.2 to establish a secure MQTT connection with a Mosquitto broker on port 8883.
During my implementation, I encountered a TLS handshake error with the following details:
mbedtls_ssl_handshake failed. -29312 (-0x7280)
I would like to confirm if mbedTLS v2.16.2, as provided in STM32CubeIDE, supports secure TLS connections (e.g., Secure MQTT) and is compatible with Mosquitto broker configurations. Additionally, I would appreciate guidance on resolving this error.
Here are some specific details about my setup:
1. mbedTLS version: 2.16.2 (as integrated into STM32CubeIDE).
2. Broker: Mosquitto, configured for secure MQTT on port 8883.
3. Issue: TLS handshake fails with the error mentioned above.
4. Certificates: [CA certificates, ].
Please let me know if additional information
Regards,
Noushad
Embedded systems engineer
Inthings Technologies Private Limited
www.inthings.tech<http://www.inthings.tech>
[cid:image001.png@01DB65BA.1F5B9660]
Dear Developer,
I was reviewing the code and noticed that in the TLS 1.3 handshake protocol state machine, the "Change Cipher Spec" state has been divided into five different states based on its occurrence timing. Could you please clarify if there are any specific considerations for this approach?
Additionally, these states can appear multiple times during a single handshake, which implies multiple "Change Cipher Spec" messages. However, the TLS 1.3 standard suggests that the "Change Cipher Spec" should only appear once in a single handshake. Could you kindly explain the rationale behind this design decision?
Thank you for your time and assistance. I look forward to your response.
Best regards,
XiangDong Li
Hi,
I am trying to determine what would be an optimal stack and heap allocation for mbedtls.
I realize this changes with algorithms, some configuration macros for the algorithms as well as concurrency.
But is there any information on stack and heap usage that I can use as a starting point? And is there any information on the same for a crypto suite.
Thanks
Michael T
Disclaimer: This message and any files or text attached to it are intended only for the recipients named above and contain information that may be confidential or privileged. If you are not an intended recipient, you must not forward, copy, use or otherwise disclose this communication or the information contained herein. In the event you have received this message in error, please notify the sender immediately by replying to this message, and then delete all copies of it from your system. Thank you.
Hello,
I am currently working on a project using STM32CubeIDE, where I am leveraging mbedTLS v2.16.2 to establish a secure MQTT connection with a Mosquitto broker on port 8883.
During my implementation, I encountered a TLS handshake error with the following details:
mbedtls_ssl_handshake failed. -29312 (-0x7280)
I would like to confirm if mbedTLS v2.16.2, as provided in STM32CubeIDE, supports secure TLS connections (e.g., Secure MQTT) and is compatible with Mosquitto broker configurations. Additionally, I would appreciate guidance on resolving this error.
Here are some specific details about my setup:
1. mbedTLS version: 2.16.2 (as integrated into STM32CubeIDE).
2. Broker: Mosquitto, configured for secure MQTT on port 8883.
3. Issue: TLS handshake fails with the error mentioned above.
4. Certificates: [Specify if you are using self-signed certificates, CA certificates, etc.].
Please let me know if additional information or logs would be helpful for diagnosing the issue.
Thank you for your assistance.
Regards,
Noushad
Embedded systems engineer
Inthings Technologies Private Limited
www.inthings.tech<http://www.inthings.tech>
[cid:image001.png@01DB5D28.96B30030]
Regards,
Noushad
Embedded systems engineer
Inthings Technologies Private Limited
www.inthings.tech<http://www.inthings.tech>
[cid:image001.png@01DB5D28.96B30030]
Dear Mbed TLS Support Team,
I am currently working on a project using Mbed TLS version 3.6 on FreeRTOS,
and I am encountering an issue with handling multiple CA certificates
during the TLS handshake process. My device has a set of built-in
certificates, and I need to try each certificate one by one to establish a
successful connection to my server. However, I am facing difficulties in
this process.
### System Information:
- **Mbed TLS version**: 3.6
- **Operating System**: FreeRTOS
- **Configuration**: Default
- **Compiler and Options**: N/A (using default configuration)
### Expected Behavior:
The first certificate (e.g., `cdotroot.cer`) cannot be verified by Mbed
TLS, while the correct certificate should successfully establish a
connection.
### Actual Behavior:
Both the incorrect and correct CA certificates fail to establish a
connection successfully.
### Steps to Reproduce:
Here is a sample of my code:
```c
static int load_and_verify_certificates(int conn_id, uint8_t *cert_buffer,
size_t buffer_size) {
int ret;
bool connection_established = false;
uint32_t cert_index = 0;
while (!connection_established && cert_index < MAX_CERT_COUNT) {
size_t cert_size = buffer_size;
// Free and initialize the certificate context
mbedtls_x509_crt_free(&cacert[conn_id]);
mbedtls_x509_crt_init(&cacert[conn_id]);
// Load the built-in certificate
ret = try_built_in_certificate(cert_buffer, &cert_size, cert_index);
if (ret == CERT_ERR_INDEX_OUT_OF_RANGE) {
break;
}
if (ret != CERT_SUCCESS) {
cert_index++;
continue;
}
// Parse the certificate
cert_buffer[cert_size] = '\0';
ret = mbedtls_x509_crt_parse(&cacert[conn_id], cert_buffer,
cert_size + 1);
if (ret < 0) {
cert_index++;
continue;
}
// Set the certificate chain
mbedtls_ssl_conf_ca_chain(&conf[conn_id], &cacert[conn_id], NULL);
// Perform the TLS handshake
ret = mbedtls_ssl_handshake(&ssl[conn_id]);
if (ret == 0) {
uint32_t flags = mbedtls_ssl_get_verify_result(&ssl[conn_id]);
if (flags == 0) {
connection_established = true;
// Cache the certificate
cache_certificate(cert_buffer, cert_size, cert_index);
break;
}
} else {
LOGD("Failed to perform handshake with certificate index %d,
error: -0x%x\n", cert_index, -ret);
}
// Reset the SSL session
ret = mbedtls_ssl_session_reset(&ssl[conn_id]);
if (ret != 0) {
LOGD("Failed to reset SSL session, error: -0x%x\n", -ret);
return ret;
}
cert_index++;
}
return connection_established ? 0 : -1;
}
```
### Additional Information:
Here are the logs:
```
Reading certificate 'cdotroot.cer' at address 0x08100650, size: 1348
Failed to perform handshake with certificate index 0, error: -0x2700
Reading certificate 'digicertroot.cer' at address 0x08100B94, size: 1360
Failed to perform handshake with certificate index 1, error: -0x7300
...
```
I suspect that the issue may be related to the limited RAM space available
on my device. I am looking for guidance on how to properly iterate through
and verify the built-in certificates within these constraints. Any
suggestions or best practices for handling multiple certificates in such an
environment would be greatly appreciated.
Thank you for your assistance.
Best regards,
[Tony]
---
Feel free to replace `[Your Name]` with your actual name before sending the
email.
Hello,
I described an issue I have here: https://github.com/Mbed-TLS/mbedtls/issues/9867
During compilation it compiles with the wrong mbedtls_config.h even though I set up this part in my CMakeLists.txt:
#MbedTLS default START
# 1. MbedTLS custom config setup
set(MBEDTLS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/mbedtls)
set(MBEDTLS_CONFIG_FILE "${CMAKE_CURRENT_SOURCE_DIR}/mbedtls_config.h")
add_compile_definitions(
MBEDTLS_CONFIG_FILE="${MBEDTLS_CONFIG_FILE}"
MBEDTLS_USER_CONFIG_FILE="${MBEDTLS_CONFIG_FILE}"
)
set(ENABLE_TESTING OFF CACHE BOOL "Disable mbedtls testing" FORCE)
set(ENABLE_PROGRAMS OFF CACHE BOOL "Disable mbedtls programs" FORCE)
set(MBEDTLS_DIR ${CMAKE_CURRENT_SOURCE_DIR}/mbedtls)
# Add mbedtls build
add_subdirectory(${MBEDTLS_DIR})
#MbedTLS END
There’s more information on the GitHub link.
Thank you in advance.
Alex