- mbed-tls - lists.trustedfirmware.org

Certificate Verify in Client Authentication does not work as expected

by Simon Nachtigall

Hello everyone, We observed a strange behavior in the mbedTLS client, when client authentication is requested by the TLS server. This behavior was observed in the newer version 3.0.0 as well as in older versions. The scenario is the following: The server selects a ciphersuite e.g. ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and sends a CertificateRequest message that only includes the ecdsa_secp256r1_sha256 signature algorithm. However, the mbedTLS client simply ignores the requested hash function and uses ecdsa_secp256r1_sha384 for the signature in the ClientVerify. Then, the server complains since the signature does not match with the requested signature algorithm and sends a handshake failure. It seems that mbedTLS does not store the requested signature algorithms/hash function from the CertificateRequest and always uses the hash function from the selected ciphersuite. In the ssl_write_certificate_verify function, we find the following comment: /* * digitally-signed struct { * opaque handshake_messages[handshake_messages_length]; * }; * * Taking shortcut here. We assume that the server always allows the * PRF Hash function and has sent it in the allowed signature * algorithms list received in the Certificate Request message. * * Until we encounter a server that does not, we will take this * shortcut. * * Reason: Otherwise we should have running hashes for SHA512 and * SHA224 in order to satisfy 'weird' needs from the server * side. */ Is this a known problem and is there any fix available? Cheers, Simon Nachtigall

2 years, 7 months

2
1
0 0

Reminder: MBed TLS Technical Forum - Asia

by Don Harbin

Hi All, A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech forum is next *Monday, Nov 7 at 10:00am UK time*. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman, cc'd, know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 7 months

1
0
0 0

Simple question about support of TLS1.2 and TLS1.3 on server side

by caoyxsh＠outlook.com

Is there a plan for adding support of TLS 1.2 and TLS 1.3 at same time on server side? According to : https://github.com/Mbed-TLS/mbedtls/blob/development/docs/architecture/tls1… only one version can be configured at runtime via `mbedtls_ssl_conf_{min,max}_tls_version` for a server endpoint.

2 years, 7 months

1
0
0 0

Get size of available application data without calling mbedtls_ssl_read()

by Bruckner, Jan

Hi all, I'd like to know if there is some way to retrieve the currently available number of bytes of application data without calling mbedtls_ssl_read()? I'm writing a "TLS socket" for higher layers to use and would like to notify them when new application data is available, tell them how much it is, but leave it up to them when and how much to retrieve. I'd like to prevent having to buffer all application data inside my TLS socket, because that would mean copying it once from mbedtls' buffer to my socket and then again from there to the application whenever it actually requests the data. After a quick look into the sources, it seems like, if at all, this might be possible for single records. But all related fields are private and I could not find any API for this. Issue #551 [1] seems related, but is more about peeking into the application data, while I would be fine with knowing just the size of available application data. Thanks for any hints on how I could achieve this. Best regards, Jan [1] https://github.com/Mbed-TLS/mbedtls/issues/551 ________________________________ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.

2 years, 8 months

1
1
0 0

Feedback requested: Mbed TLS builds with PSA and legacy implementations of the same algorithm with different characteristics

by Gilles Peskine

Hello, Summary: I am soliciting feedback about builds of Mbed TLS where *there is both a PSA implementation and the built-in software implementation of the same algorithm, by design, *and the PSA implementation isn't just calling the built-in implementation because the two have different characteristics, each desirable in some context. Please read this message if you are doing this or considering it. Feel free to ignore otherwise. For example, both MBEDTLS_SHA256_C and MBEDTLS_PSA_ACCEL_ALG_SHA_256 are enabled, so that calls to mbedtls_md_xxx() use the software implementation and calls to psa_hash_xxx() use the hardware accelerator via the PSA driver. And this is deliberate: there is a reason why mbedtls_md_xxx() must not call the PSA driver. In most cases, this is not desirable: if there's an accelerator, why not use it? And we're working to allow getting rid of the software implementation in more and more cases. Ultimately, PSA will be the only crypto interface in Mbed TLS, so all interfaces to calculate SHA-256 will go through psa_hash_xxx() and therefore will dispatch the call to the driver if there is one. This will be an API break, since it will require calling psa_crypto_init() before performing any cryptography. Currently we are planning to introduce this requirement in Mbed TLS 4.0. But it is currently possible to have dual algorithm support, and I can think of unusual cases where it might desirable. Scenario 1, with accelerator drivers: there is a driver, but it can only be used after some initialization. The application needs to use the algorithm before calling psa_crypto_init(), so it calls the legacy interface. After psa_crypto_init() has been called, the application would like to use the driver as much as possible. A typical use case is a bootloader which wants to verify a signature before initializing the random generator, so it calls mbedtls_md_xxx() and mbedtls_rsa_xxx(). Scenario 1 is clearly desirable, and for that we have a planned solution, which is staged initialization. The bootloader will be able to (1) initialize drivers, (2) perform a hash calculation, (3) initialize the keystore, (4) verify a signature, all without initializing the RNG. We won't make psa_crypto_init() mandatory until this feature is implemented. Scenario 2: with a cryptography service. This is a build of Mbed TLS with MBEDTLS_PSA_CRYPTO_CLIENT, so all psa_xxx() calls call the service. But, for some reason, there is also a local implementation of some cryptography algorithms. So you can call mbedtls_md() to calculate a hash even before the connection to the service has been established. Or maybe you want to call mbedtls_md() for short messages and psa_hash_compute() for long messages, because the crypto service has a faster implementation but the communication overhead offsets the gain for short messages. We are currently working on improving support for PSA drivers, and in particular, saving code size by eliminating more unnecessary code when a driver is present, and increasing the set of APIs that benefit from drivers. The obvious way to do that is to make all cryptography calls (especially from X.509 and TLS) go via the PSA interface, but we can't do that yet due to the need to have initialized the keystore and RNG. We are considering routing /certain/ crypto calls via PSA, in a way that would break scenario 2, and would also break scenario 1 in some cases, but not for hashes or signature verification. If, for example, in Mbed TLS 3.4, mbedtls_md() starts calling psa_hash_(), would this break your code? Are you in scenario 1, scenario 2, or some other variant I haven't thought of? If so, *please reply to this message and let us know what your needs are*. Feel free to reply to me in private if you don't want to discuss this publicly (I won't share directly outside Arm, but the eventual design might leak information about the unusual scenario). If we don't hear objections, there is a chance that a future Mbed TLS 3.x will break scenarios 1 and 2. If we do hear objections, we'll work to keep the current behavior or arrange a migration path. Best regards, -- Gilles Peskine Mbed TLS developer

2 years, 8 months

1
1
0 0

problem PSA_CRYPTO (Mbedtls 2.28.0)

by xlin＠murata.com

I have port mbedtls 2.28.0 into my platform and am able to connect to a few websites in PKI mode. But after enabling MBEDTLS_USE_PSA_CRYPTO & MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG, with everything else stay the same, I can't connect to the same websites anymore. in the working case (no MBEDTLS_USE_PSA_CRYPTO), after the client (my app) sends "Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message", the server responds with "Change Cipher Spec, Encrypted Handshake Message". In the broken case (with MBEDTLS_USE_PSA_CRYPTO), after the client (my app) sends "Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message", the server doesn't respond with "Change Cipher Spec, Encrypted Handshake Message". I don't know how to debug the issue, any suggestion what my cause the server to drop off at the last step?

2 years, 8 months

1
0
0 0

How much bigger is MbedTLS 2.28.1 relative to 2.16.2? (STM 32F417 GCC)

by Peter

I may need TLS 1.3 support which I believe arrived in 2.28, or maybe a bit later. I don't want to change to TLS 3 just yet. It looks like many changes. My target is "OK" on FLASH (150k of the 350k total code size) but is tight on RAM (after allocating 50k for the MbedTLS heap, we have just 20k RAM left). Ideally I would like the very last version of v2. The problem just found is that Cloudflare is asking for TLS 1.3 which MbedTLS 2.16 does not support. But it may be that Cloudflare can fall back and the problem is elsewhere. Many thanks for any input.

2 years, 8 months

2
1
0 0

Performance tuning of SHA256 on big files

by Liu James

Hi, This is an updated post from https://github.com/Mbed-TLS/mbedtls/issues/6464, which should be posted in mbedtls mail list. My question is how to significantly improve SHA256 performance on big files (regardless of architectures). *=== Updates* I use same code with mbedtls-3.1.0 to run tests in x86, and performance is still downgraded. Mbed TLS version (number or commit id): *3.1.0* Operating system and version: * Centos-8.5, CPU 11900K* Configuration (if not default, please attach mbedtls_config.h): Compiler and options (if you used a pre-built binary, please indicate how you obtained it): *gcc/g++ 8.5* Additional environment information: *Test files and performance* CentOS-8.5.2111-x86_64-boot.iso (827.3 MB): sha256 *5 sec* CentOS-8.5.2111-x86_64-boot.iso (10.79 GB): sha256 *66 sec* Also, as advised I try to turn on "MBEDTLS_SHA256_USE_A64_CRYPTO_IF_PRESENT " and "MBEDTLS_SHA512_USE_A64_CRYPTO_IF_PRESENT" using mbedtls-3.2.0 in M1, but compiler reported the following error: CMake Error at library/CMakeLists.txt:257 (add_library): Cannot find source file: psa_crypto_driver_wrappers.c Tried extensions .c .C .c++ .cc .cpp .cxx .cu .mpp .m .M .mm .ixx .cppm .h .hh .h++ .hm .hpp .hxx .in .txx .f .F .for .f77 .f90 .f95 .f03 .hip .ispc CMake Error at library/CMakeLists.txt:257 (add_library): No SOURCES given to target: mbedcrypto Thanks for your help. *=== Original message at github* Summary sha256() and sha1() incurs significant overhead on big files(~1G above). *This might not be an issue*, and I'm looking for an efficient way to calculate hash on big files. System information Mbed TLS version (number or commit id): 3.1.0 Operating system and version: M1 OSX Configuration (if not default, please attach mbedtls_config.h): Compiler and options (if you used a pre-built binary, please indicate how you obtained it): Clang++ Additional environment information: Expected behavior Fast calculation of big files in less than 1 second Actual behavior Test files: CentOS-8.5.2111-x86_64-boot.iso (827.3 MB): sha1 *3.3 sec*, sha256 *5.9 sec* CentOS-8.5.2111-x86_64-boot.iso (10.79 GB): sha1 *40 sec*, sha256 *78 sec* Steps to reproduce ISO files can be downloaded at: http://ftp.iij.ad.jp/pub/linux/centos-vault/8.5.2111/isos/x86_64/ Make sure use fast disk, say nvme, to store ISO files, or else loading big files could take lots of time. Also use user from time command to measure performance. Workable code of sha256: string test_sha256(string file_path) { mbedtls_sha256_context ctx; FILE *fp; string output; int BUFFER_SIZE = 4096; uint8_t buffer[BUFFER_SIZE]; size_t read, k_bytes; uint8_t hash[32]; mbedtls_sha256_init(&ctx); mbedtls_sha256_starts(&ctx, 0); fp = fopen(file_path.c_str(), "r"); if (fp == NULL) { mbedtls_sha256_free(&ctx); return output; } while ((read = fread(buffer, 1, BUFFER_SIZE, fp))) { mbedtls_sha256_update(&ctx, buffer, read); } mbedtls_sha256_finish(&ctx, hash); mbedtls_sha256_free(&ctx); fclose(fp); // update hash string, omit here return output; }

2 years, 8 months

4
5
0 0

Is there a server somewhere which can be used for testing various MbedTLS client cipher suites

by Peter

Hi All, There are machines out there for testing servers but I don't know of one which can be used for testing a client. This is a tricky area. For example I have a board running, LWIP and MbedTLS, uploading little test files to two sites. One was running EC and AES256. It worked fine. The other was running RSA and AES256 but didn't work, and after some work it was found that its certificate chain was running SHA-1 on the top level certificate, dated 2006. This is actually a major name on the internet! And we didn't have SHA-1 enabled because it is supposed to be deprecated. I wonder if there is some practical way to test out all this. We can probably enable all the MbedTLS crypto options (TLS is taking up 150k out of 350k of code for the whole product, but we can probably throw in some more) but testing them is something else. There is a test suite in TLS but it needs to be embedded in the product itself. Has someone implemented that code on a server somewhere? Thank you in advance for any pointers. Peter

2 years, 8 months

1
0
0 0

Error about psa_crypto_init

by 韩轾

I meet a problem when I call function `psa_crypto_init`, it return error code -148 that was PSA_ERROR_INSUFFICIENT_ENTROPY. I track this function step by step and found it caused by MBEDTLS_ERR_ENTROPY_NO_SOURCES_DEFINED. Code in entropy.c, if( ctx->source_count == 0 ), return this error. My question: I run code on Ubuntu, it runs well. But in some arm board, it returns this error. Why this count will be 0 sometimes? What is the root cause of this error.

2 years, 8 months

2
1
0 0

Reminder: MBed TLS Technical Forum - US/Europe

by Don Harbin

Hi All, A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum is next Monday at 4:30 PM UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 8 months

1
0
0 0

PKCS#7 format of certificate

by Subramanian Gopi Krishnan

Hi, I have developed a TLS and EST client application. Where the EST server issues the certificate in PKCS#7 format. It seems mbedtls library not support certificates in PKCS#7 format. Is there any plan to support PKCS#7 in future? Thanks, Gopi Krishnan

2 years, 8 months

1
0
0 0

Reminder: MBed TLS Technical Forum - Asia

by Don Harbin

Hi All, A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech forum is next *Monday, Oct 10 at 10:00am UK time*. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman, cc'd, know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 8 months

2
1
0 0

Re: Writing mbedtls_x509_crt chain to PEM ?

by Nicolas Pillot

Hello Please note that this is a repost from my previous message from yesterday as it seemd to have bugged (empty text + html attachement) when viewed from the archive. Apologies. Short question : how do i output an in-memory mbedtls_x509_crt chain to PEM text ? Context : I have a project where the user provides a PEM bundle to be used for HTTPS As it is provided by a user, may be incomplete or malformed : - no private key - more than 1 private key - no certificate at all - duplicate certificates - no certificate matching the private key - broken chain - extraneous certificates not part of the chain… So i want to full validate user input. Here is what i have succeeded so far : - parse the bundle into atomic parts, based on « BEGIN/END » labels - try to mbedtls_x509_crt_parse / mbedtls_pk_parse_key each part (no chain) - check that i only have one private key in the bundle - search for the certificat C matching the private key - starting from that atomic certificate, verify it against each other candidate certificate - if it validates, add it to the chain of C, and repeat until no candidate validates - then check that there are no remaining certificate (which never validated anything) - finally print and store the chain (as it’s now deemed correct and minimal) Now i want to store it in PEM format for later use. But i do not understand the way to do it : - there are no write functions for mbedtls_x509_crt - the mbedtls_x509write_cert structure shares few members with mbedtls_x509_crt - i have not found yet how to get/convert many of the missing members - as memory is tight i have have cleaned the « atomic parts » text buffers (but if there is no other way, i'll keep and reuse them) I guess it should be pretty simple, but i cannot wrap my head around it. Thanks in advance for your help Nicolas PS : if steps 1-8 could be done more elegantly, please do not hesitate to point me in the right direction.

2 years, 9 months

1
0
0 0

Writing mbedtls_x509_crt chain to PEM ?

by Nicolas PILLOT

2 years, 9 months

1
0
0 0

Mbed TLS4.0 - Remove legacy cipher APIs

by S Krishnan, Archanaa

Hi, In mbedTLS road map, there is a future task to remove legacy cipher API (https://developer.trustedfirmware.org/w/mbed-tls/roadmap/). Does that mean all existing mbedtls crypto APIs will not be supported anymore? mbedTLS is used for both its TLS and crypto library. I am curious how the planned changes will affect both set of users. * Are the crypto library users expected to only use PSA crypto APIs and key IDs? * Are the TLS library users expected to see API changes to TLS functions to support key IDs? Thank, Archanaa

2 years, 9 months

4
3
0 0

Question about handshake MTU

by Martin Man

Hi guys, I use mbedtls for years (since 2.10 IIRC) upgrading to latest available as time goes by. For DTLS that is. I remember a case in the past where a link would have a small MTU (around 500 bytes) and I had to tune ssl_context.handshake.mtu to a lower value to successfully complete handshakes. I do not remember exactly why, but I did not want to actually restrict maximum value via mbedtls_ssl_set_mtu, maybe it was even ignored back then for handshakes… but Now when working on migration to 3.2.1 (gave some time to 3x releases to stabilize) I noticed that the whole ssl_context.handshake member is now private and inaccessible, which I guess is fine. Could somebody with more knowledge of the code recommend what is the best strategy for DTLS app where MTU may not always be 1400? thanks a lot for your time, Martin

2 years, 9 months

4
7
0 0

Regarding Connection ID (RFC 9146) support in Mbed TLS

by Jérémy Audiger

Hi everyone, I would like to know what is the current support of Mbed TLS regarding the RFC 9146 (https://datatracker.ietf.org/doc/html/rfc9146) published in March 2022. Mbed TLS is currently supporting a draft version of this RFC (https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls-connection-id-05) through the define MBEDTLS_SSL_DTLS_CONNECTION_ID, but I just wanted to know the progress on supporting the newly RFC released this year. Are there any plan to support it soon ? If yes, will it be in the coming weeks / months (i.e.: next release) ? I'm asking since I'm currently playing with the Connection ID on both a DTLS 1.2 Server and DTLS 1.2 Client. Anyway, have a nice day, Best regards, Jérémy Audiger [ioterop-your-lwm2m-partner]<https://ioterop.com/> [social-icon-linkedin]<https://www.linkedin.com/company/7955832/> [social-icon-twitter] <https://twitter.com/ioteropcompany> [social-icon-facebook] <https://www.facebook.com/IoteropCompany/>

2 years, 9 months

2
1
0 0

Reminder: MBed TLS Technical Forum - US/Europe

by Don Harbin

Hi All, A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum is next Monday at 4:30 PM UK time. Invite details can be found on the online calendar here <https://www.trustedfirmware.org/meetings/>. If you have any topics, please let Dave Rodgman know. :) Best regards, Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

2 years, 9 months

1
0
0 0

Re: What am I doing wrong?

by Marco Nilsson

We're seeing pretty much the same issue on 3.0.0 ARM. However, if I build the ssh_client2 tool on my host machine (x64) and try to mimic the config as close as possible, it works just fine. Do you think we're seeing the same problem? Will try with a newer version next week.

2 years, 9 months

1
0
0 0

HMAC and CMAC Verification

by Ahmed Mohammed

Hello, I am wondering if there are APIs for Hmac and Cmac verification? from md.h and cmac.h, Hmac and Cmac generation functionalities are provided in a single and streaming approach. But is there a plan to add verification APIs for future releases maybe? Kind regards, Ahmed Mohammed

2 years, 9 months

2
1
0 0

User configuration

by Ahmed Mohammed

Hello, What is the difference between these two macros in include/mbedtls/build_info.h: MBEDTLS_CONFIG_FILE MBEDTLS_USER_CONFIG_FILE In other words, why would I have two different user configuration files? Or I misunderstand the difference between such files. Kind regards, Ahmed Mohammed

2 years, 9 months

2
1
0 0

Slowness in verification of a ecdsa secp256r1 signature using S32K Microcontroller (clock speed 112MHz) - bare metal implementation

by ammar.ahmed.mughal＠gmail.com

I am verifying a signature generated using ecdsa secp256r1. The signature is getting verified but the time taken by the verification step is too long. It takes 4-5 seconds to verify the signature. The implementation is bare metal i.e. no RTOS (one realizes the use of RTOS but still the time is too long). Can you please guide a way around for this issue. How to make it work faster , the ideal verification time would be 30ms - 60ms. Here is a gist of my code mbedtls_ecp_curve_info *curve_info = NULL; mbedtls_ecdsa_context ecdsa_context; /// Initialization mbedtls_ecdsa_init(&ecdsa_context); curve_info = mbedtls_ecp_curve_info_from_tls_id(23); /// 23 is tls_id of secp256r1 mbedtls_ecp_group_load(&ecdsa_context.grp, curve_info->grp_id); /// Processing result = mbedtls_ecp_point_read_binary( &ecdsa_context.grp, &ecdsa_context.Q, public_key_data, // public key data in uncompressed format i.e. including leading 0x04 sizeof(public_key_data) ); /// 32 /// 71 status_verify_signature = mbedtls_ecdsa_read_signature(&ecdsa_context, hash, sizeof(hash), signature, sizeof(sig)); /// converts the signature data to ASN1, verifies the signature Thank you :)

2 years, 9 months

2
1
0 0

Mutual authentication support in Embed tls

by Anupma Jain

Hello, Can please provide me with any example on "how to achieve Mutual authentication(Client and server certificate validation)" in mbed-tls. Please help me with this.It is a little urgent. Thank you Regards Anupma Jain

2 years, 9 months

1
0
0 0

Website update

by Dave Rodgman

Hi all, Apologies for the website outage. We have now restored the majority of the old content, which is reachable via our Trusted Firmware website (the old website address will redirect here). The new location for our documentation, including the knowledge base and security advisories, is: https://mbed-tls.readthedocs.io/en/latest/ Please let us know (on the mailing list, via the Tech Forum, or raise a GitHub issue or PR) if you find any issues or missing documentation. The source repository for the docs is here: https://github.com/Mbed-TLS/mbedtls-docs Community contributions to the docs are welcome! Regards Dave Rodgman

2 years, 10 months

2
1
0 0

2025

2024

2023

2022

2021

2020

mbed-tls