- mbed-tls - lists.trustedfirmware.org

Re: [mbed-tls] Question about dynamic linking, versioning and API/ABI stability

by Janos Follath

Hi, Semantic versioning applies only to API compatibility but not for ABI. When we break the ABI we increase the SO version for that part of the library and this is how linux distributions normally track our ABI compatibility. Additionally, we try very hard not to break ABI at all in LTS versions. You can find a detailed description what Mbed TLS promises regarding API/ABI compatibility: https://github.com/ARMmbed/mbedtls/blob/development/BRANCHES.md Kind regards, Janos From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Hugues De Valon via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Date: Wednesday, 14 July 2021 at 17:09 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Question about dynamic linking, versioning and API/ABI stability Hello, We are using Mbed Crypto in our Parsec project through the psa-crypto Rust crate (https://github.com/parallaxsecond/rust-psa-crypto). We currently have Mbed Crypto through Mbed TLS 2.25.0 which we build statically from scratch by default. We also offer the option to dynamically link with an Mbed Crypto library available on the system. Ideally, this would offer an easy and simple way to patch bug fixes without having to recompile everything. However, as we observed API (and probably ABI) breaking changes over the past versions of Mbed TLS we were wondering if this (dynamic linking) was a model we should promote at all. Is there a semantic versioning process currently applied in Mbed TLS? If we use Mbed TLS 3.0.0 in our crate, can we be sure than 3.x.y versions won’t contain any API/ABI breaking changes or is there nothing of the sort? I believe that Mbed Crypto is catching up to be fully compliant with PSA Crypto 1.0.1. Once that will be the case, will its API/ABI be stable and follow the PSA Crypto semantic versioning? It might be that the good solution is that we shouldn’t dynamically link with Mbed Crypto but always compile it from scratch as we do by default. I am just sending this email so that we follow the good approach! Kind regards, Hugues

3 years, 9 months

2
2
0 0

Question about dynamic linking, versioning and API/ABI stability

by Hugues De Valon

Hello, We are using Mbed Crypto in our Parsec project through the psa-crypto Rust crate (https://github.com/parallaxsecond/rust-psa-crypto). We currently have Mbed Crypto through Mbed TLS 2.25.0 which we build statically from scratch by default. We also offer the option to dynamically link with an Mbed Crypto library available on the system. Ideally, this would offer an easy and simple way to patch bug fixes without having to recompile everything. However, as we observed API (and probably ABI) breaking changes over the past versions of Mbed TLS we were wondering if this (dynamic linking) was a model we should promote at all. Is there a semantic versioning process currently applied in Mbed TLS? If we use Mbed TLS 3.0.0 in our crate, can we be sure than 3.x.y versions won't contain any API/ABI breaking changes or is there nothing of the sort? I believe that Mbed Crypto is catching up to be fully compliant with PSA Crypto 1.0.1. Once that will be the case, will its API/ABI be stable and follow the PSA Crypto semantic versioning? It might be that the good solution is that we shouldn't dynamically link with Mbed Crypto but always compile it from scratch as we do by default. I am just sending this email so that we follow the good approach! Kind regards, Hugues

3 years, 9 months

1
0
0 0

serial communication in FTP

by Sunil Jain

Hello, we are using the mbed-tls for secure communication for FTP. FTP server is handling the client hello serially one at a time, one communication is blocking other clients to communicate. What could be the reason and how to solve this issue. -- Thanks and Regards, Sunil Jain

3 years, 9 months

1
0
0 0

Mbed TLS: Release of Mbed TLS 3.0.0, 2.27.0, and 2.16.11

by Dave Rodgman

Hi Mbed TLS users, We are pleased to announce the release of Mbed TLS versions 3.0.0, 2.27.0 and 2.16.11. These releases of Mbed TLS address several security issues, and provide bug fixes and enhancements. Mbed TLS 3.0.0 also brings many API-breaking changes. Full details, including security advisories, are available in the release notes: https://github.com/ARMmbed/mbedtls/releases/tag/v3.0.0 https://github.com/ARMmbed/mbedtls/releases/tag/v2.27.0 https://github.com/ARMmbed/mbedtls/releases/tag/v2.16.11 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Dave Rodgman

3 years, 9 months

1
0
0 0

Mbed TLS: Release of Mbed TLS 3.0.0, 2.27.0, and 2.16.11

by Dave Rodgman

Hi Mbed TLS users, We are pleased to announce the release of Mbed TLS versions 3.0.0, 2.27.0 and 2.16.11. These releases of Mbed TLS address several security issues, and provide bug fixes and enhancements. Mbed TLS 3.0.0 also brings many API-breaking changes. Full details, including security advisories, are available in the release notes: https://github.com/ARMmbed/mbedtls/releases/tag/v3.0.0 https://github.com/ARMmbed/mbedtls/releases/tag/v2.27.0 https://github.com/ARMmbed/mbedtls/releases/tag/v2.16.11 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Dave Rodgman

3 years, 9 months

1
0
0 0

Re: [mbed-tls] mbedtls_x509_crt_parse returned -0x2180

by Danny Backx

Gilles, Thanks for getting me to try to read DER files. There must definitely be something wrong in that area. I am speficying support for PEM in the build but reading DER gets me past that error. Searching further :-) Again, thanks Danny On 05/07/2021 20:27, Gilles Peskine via mbed-tls wrote: > Hello, > > The first thing when you see an unexpected error code is to look up the > corresponding error message. Mbed TLS comes with a utility for that: > > programs/util/strerror 0x2180 > Last error was: -0x2180 - X509 - The CRT/CRL/CSR format is invalid, > e.g. different type expected > > You can also search the error code in the source code: > > grep 0x2180 include/mbedtls/*.h > include/mbedtls/x509.h:#define > MBEDTLS_ERR_X509_INVALID_FORMAT -0x2180 /**< The > CRT/CRL/CSR format is invalid, e.g. different type expected. */ > > At first glance it looks like there's only one case for which CRT > parsing return MBEDTLS_ERR_X509_INVALID_FORMAT as opposed to > (MBEDTLS_ERR_X509_INVALID_FORMAT + low_level_error_code), and that's if > the certificate doesn't parse like a DER format at the top level. A > plausible reason for that is that the certificate is in PEM format and > your build has PEM support turned off. If that's the case, convert the > certifcate to DER when you copy it to the device. You can use the Mbed > TLS utility programs/util/pem2der for that. > > Best regards, > -- Danny Backx - dannybackx(a)telenet.be - http://danny.backx.info

3 years, 9 months

1
0
0 0

SHA NI support in mbedtls

by Lu, Jingdong

Hi, mbedtls experts I note that there is AES NI support (aesni.c) on x86 platform. I'm wondering why there is no SHA NI support for SHA1 and SHA256? How can I get SHA NI support? Should I choose another crypto library? Thanks, Jingdong

3 years, 9 months

1
0
0 0

Re: [mbed-tls] mbedtls_x509_crt_parse returned -0x2180

by Gilles Peskine

Hello, The first thing when you see an unexpected error code is to look up the corresponding error message. Mbed TLS comes with a utility for that: programs/util/strerror 0x2180 Last error was: -0x2180 - X509 - The CRT/CRL/CSR format is invalid, e.g. different type expected You can also search the error code in the source code: grep 0x2180 include/mbedtls/*.h include/mbedtls/x509.h:#define MBEDTLS_ERR_X509_INVALID_FORMAT -0x2180 /**< The CRT/CRL/CSR format is invalid, e.g. different type expected. */ At first glance it looks like there's only one case for which CRT parsing return MBEDTLS_ERR_X509_INVALID_FORMAT as opposed to (MBEDTLS_ERR_X509_INVALID_FORMAT + low_level_error_code), and that's if the certificate doesn't parse like a DER format at the top level. A plausible reason for that is that the certificate is in PEM format and your build has PEM support turned off. If that's the case, convert the certifcate to DER when you copy it to the device. You can use the Mbed TLS utility programs/util/pem2der for that. Best regards, -- Gilles Peskine Mbed TLS developer On 05/07/2021 18:10, Danny Backx via mbed-tls wrote: > > Hi, > > I must be missing something obvious but my code (on an ESP32) fails to > accept an incoming connection. > > I tried the same certificate on an ESP32 sample, and it appears to > work there. > > Does anyone have a clue where to look next ? > > Danny > > I (16:06:51.481) esp_https_server: performing session handshake > E (16:06:51.483) x509_crt: x509_crt_parse_der_core -> 0x2180 > E (16:06:51.484) esp_tls_mbedtls: set_pki_context: public_cert > 0x3ffdb924, len 5750 -> ret 0x2180 > E (16:06:51.493) esp-tls-mbedtls: mbedtls_x509_crt_parse returned -0x2180 > E (16:06:51.501) esp-tls-mbedtls: Failed to set server pki context > E (16:06:51.508) esp-tls-mbedtls: Failed to set server configurations > E (16:06:51.515) esp-tls-mbedtls: create_ssl_handle failed > E (16:06:51.521) esp_https_server: esp_tls_create_server_session failed > W (16:06:51.528) httpd: httpd_accept_conn: session creation failed > W (16:06:51.538) httpd: httpd_server: error accepting new connection > > -- > Danny Backx - dannybackx(a)telenet.be - http://danny.backx.info >

3 years, 9 months

1
0
0 0

mbedtls_x509_crt_parse returned -0x2180

by Danny Backx

Hi, I must be missing something obvious but my code (on an ESP32) fails to accept an incoming connection. I tried the same certificate on an ESP32 sample, and it appears to work there. Does anyone have a clue where to look next ? Danny I (16:06:51.481) esp_https_server: performing session handshake E (16:06:51.483) x509_crt: x509_crt_parse_der_core -> 0x2180 E (16:06:51.484) esp_tls_mbedtls: set_pki_context: public_cert 0x3ffdb924, len 5750 -> ret 0x2180 E (16:06:51.493) esp-tls-mbedtls: mbedtls_x509_crt_parse returned -0x2180 E (16:06:51.501) esp-tls-mbedtls: Failed to set server pki context E (16:06:51.508) esp-tls-mbedtls: Failed to set server configurations E (16:06:51.515) esp-tls-mbedtls: create_ssl_handle failed E (16:06:51.521) esp_https_server: esp_tls_create_server_session failed W (16:06:51.528) httpd: httpd_accept_conn: session creation failed W (16:06:51.538) httpd: httpd_server: error accepting new connection -- Danny Backx - dannybackx(a)telenet.be - http://danny.backx.info

3 years, 9 months

1
0
0 0

Hardware CCM decrypt failure

by Navin Reddy

Hello everyone, I am currently evaluating SSL with a local server and an STM32 device. I'm unable to figure out why the decryption fails with CCM as the cipher suite. FYI: I am using MbedTLS *v2.14.1.* *Setup*: I'm using *x86 local server* with *STM32* device as a client. Here is what happens- 1. Software CCM implementation on the client: When I use the *software* implementation of the CCM. Handshake and decryption is *successful*. Therefore, I can stream the data from STM32 and read it on the local server. 2. Hardware CCM implementation with MBEDTLS_CCM_ALT: I have used ccm_alt.c provided from STM32Cube v1.9.0. Here, the handshake is successful. But *decrypting* the message *fails*. The errors are: ssl_decrypt_buf() returned -29056 (-0x7180) mbedtls_ssl_read_record() returned -29056 (-0x7180) Checks performed: - Same certificates are used for SW and HW implementations. - CCM self test returns '0' for both HW and SW CCM implementations. - I have reserved enough heap, no memory issues. Please find all the necessary data in the attachment provided. I have added the logs from the server and the client. I have added the certificates and the code files as well. It would be of great help if somebody could point at what might be going wrong. Thank you! Best regards, Navin

3 years, 9 months

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls