- mbed-tls - lists.trustedfirmware.org

Uninitialized variable in rsa_prepare_blinding

by momo 19

Hello, I would like to report a possible bug in rsa_prepare_blinding function in rsa.c (https://github.com/ARMmbed/mbedtls/blob/v2.26.0/library/rsa.c). I am not sure if it is a real issue, but I think that there is a possibility to use uninitialized variable ret: static int rsa_prepare_blinding( mbedtls_rsa_context *ctx, int (*f_rng)(void *, unsigned char *, size_t), void *p_rng ) { int ret, count = 0; <--- uninitialized variable ret mbedtls_mpi R; mbedtls_mpi_init( &R ); if( ctx->Vf.p != NULL ) { /* We already have blinding values, just update them by squaring */ MBEDTLS_MPI_CHK( mbedtls_mpi_mul_mpi( &ctx->Vi, &ctx->Vi, &ctx->Vi ) ); MBEDTLS_MPI_CHK( mbedtls_mpi_mod_mpi( &ctx->Vi, &ctx->Vi, &ctx->N ) ); MBEDTLS_MPI_CHK( mbedtls_mpi_mul_mpi( &ctx->Vf, &ctx->Vf, &ctx->Vf ) ); MBEDTLS_MPI_CHK( mbedtls_mpi_mod_mpi( &ctx->Vf, &ctx->Vf, &ctx->N ) ); goto cleanup; <--- going to cleanup without setting a value of ret } (Skipping lines for readability) cleanup: mbedtls_mpi_free( &R ); return( ret ); <--- returning uninitialized variable ret } Best regards, grapix121

4 years, 2 months

1
0
0 0

Re: [mbed-tls] Signing messages with ECDSA

by stefano664

Excuse me, I replied to your e-mail without note that I'm replying to your address instead of mailing-list address. Now I'll do some other tests, starting from a blank project. I can't send a fully compilable FW because my target is an ESP32 with an OPTIGA crypto chip connected,. than it is necessary to have my hardware to run it. But attached I put my mbedtls configuration. Thank you, Stefano Il giorno mer 21 apr 2021 alle ore 14:36 Gilles Peskine < gilles.peskine(a)arm.com> ha scritto: > I adjusted your code to compile and added the missing definitions and > declarations, and this version works for me. I've attached my code. Here's > the output I get (Mbed TLS , default configuration): > > Message: PLUTOxPLUTOxPLUTOxPLUTOxPLUTOxxx > Private key: -----BEGIN EC PRIVATE KEY----- > MIGkAgEBBDCv5Vq0yRsOKLkkaI0lR32vByL9MB+4O0f+bhVErb8Fd0W1XFhN1897 > iAtnV/DeXDygBwYFK4EEACKhZANiAARgYE9uzG+nXYDoydWyDE6wrlgxiRKqm6kg > si00tFa0KD//vCemOAoYAmmbtFd9RvE6tNOw+Ze5eRtVvosmvYl5IoWx4Jda+Wv9 > ftRXkUk3nRzcAmXnG7bGmgwNC2iC73s= > -----END EC PRIVATE KEY----- > > Hash: yrmtrgMb4WzvHD5XWwb00yAE13RCi934x2ySjcWup5g= > Signature: MGQCMD8pezXqUF6v01b0WQiIUZWuuvxPR1tT15YnN9atogKR2pBPizBYbbhjAIz+ftm78AIwDogKWZVxDk5r6I38oIn0JALO7h8EcTCwjUsulYS5BRl8iyITAC42Xx+HlRPofwbr > Public key: -----BEGIN PUBLIC KEY----- > MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEYGBPbsxvp12A6MnVsgxOsK5YMYkSqpup > ILItNLRWtCg//7wnpjgKGAJpm7RXfUbxOrTTsPmXuXkbVb6LJr2JeSKFseCXWvlr > /X7UV5FJN50c3AJl5xu2xpoMDQtogu97 > -----END PUBLIC KEY----- > > > I don't think I can be of any more help unless you post code to reproduce > the problem that can be compiled and run a popular platform (preferably > Linux) without modifications, and also your library configuration > (mbedtls/config.h). Preferably post those on the mailing list, because I > personally have limited time and I'm not sure when I'll next be able to > take a look. > > Best regards, > > -- > Gilles Peskine > Mbed TLS developer > > > On 21/04/2021 14:14, stefano664 wrote: > > I'm sure that the problem isn't here. > > 1) mbedtls_base64_encode is used only to generate human readable data in > this case, and to print it. The chain have the same behaviour without these. > > 2) I changed len_b64 and olen type to size_t and removed casting. I have > the same result and verify fails... > > Here the new code: https://wtools.io/paste-code/b4Hy > > Here the new output: https://wtools.io/paste-code/b4H0 > > Do you have some other idea? > Thanks a lot for your help! > > Stefano > > > Il giorno mer 21 apr 2021 alle ore 13:36 Gilles Peskine < > gilles.peskine(a)arm.com> ha scritto: > >> Ok, I found the problem: >> >> mbedtls_base64_encode(hash_b64, sizeof(hash_b64), (size_t *) &len_b64, hash, 32); >> >> >> &len_b64 is a pointer to uint16_t. Casting the pointer to size_t* doesn't >> give you a pointer to a size_t object, it gives you an invalid pointer >> since it isn't pointing to a size_t object. When mbedtls_base64_encode >> writes through that pointer, it overwrites whatever is next on the stack. >> Other calls with a size_t* cast have the same problem. Depending on exactly >> how your compiler lays out the stack, this might part of the message, or >> part of the pk structure, or part of the result... >> >> I found this problem because I massaged your code until it ran on Linux, >> and it crashed during mbedtls_pk_sign because the pk structure had been >> corrupted. Other potential ways to find such problems include static >> analysis (Coverity is good but very expensive), AddressSanitizer (if you >> can build your code on a platform that has enough space), and of course >> code review (any cast is suspicious: most of the times, when a compiler >> complains about something, a cast will silence the compiler but not >> actually fix the problem). >> >> Best regards, >> >> -- >> Gilles Peskine >> Mbed TLS developer >> >> On 21/04/2021 09:43, stefano664 wrote: >> >> Hi Gilles, >> thanks for your reply. >> >> The posted code is without error checks to be smaller. The complete code >> is here: >> >> https://wtools.io/paste-code/b4Hi >> >> All error checks pass true than all functions seems ok. >> >> In this version I added also the verify, that fail. >> >> Here you can find the output with all prints, messages and datas: >> >> https://wtools.io/paste-code/b4Hj >> >> As you can see my signature is 71 byte wide, a bit too little even after >> zeroes removing. The same made with openSSL is 104 byte wide. >> I've checked my keys, and I confirm it is 384 bit. You can check, it is >> printed during process. >> >> Thanks a lot for your help! >> >> Best regards, >> Stefano >> >> >> Il giorno mar 20 apr 2021 alle ore 21:48 Gilles Peskine via mbed-tls < >> mbed-tls(a)lists.trustedfirmware.org> ha scritto: >> >>> Hi Stefano, >>> >>> Assuming that the key is in PEM format and that the buffers (hash, tmp) >>> are large enough, I don't see anything wrong in the part of the code you >>> posted. >>> >>> You posted code without error checking. Can you confirm that all >>> functions return 0? >>> >>> mbedtls_pk_sign produces ECDSA signatures in ASN.1 format. The size of >>> the signature can be up to 104 bytes, and is often a few bytes shorter >>> because it consists of numbers in which leading zeros are omitted. Make >>> sure the tmp buffer is large enough. You can use >>> MBEDTLS_ECDSA_MAX_SIG_LEN(384) or MBEDTLS_ECDSA_MAX_LEN (from >>> mbedtls/ecdsa.h) as the signature buffer size. >>> >>> 72 bytes is the maximum size of a signature for a 256-bit key, reached >>> about 25% of the time. Are you sure you're signing with the key you >>> intended? >>> >>> People may be able to help more if you post complete code that we can >>> run on our machine. >>> >>> Best regards, >>> >>> -- >>> Gilles Peskine >>> Mbed TLS developer >>> >>> On 20/04/2021 16:49, stefano664 via mbed-tls wrote: >>> > Hi all, >>> > I have some problems with mbedTLS during ECDSA signing process. >>> > >>> > I followed the example supplied with the source code and write this >>> code: >>> > >>> > mbedtls_pk_init(&pk); >>> > mbedtls_pk_parse_key(&pk, (const unsigned char *) >>> > flash.flash_ver0.ecc_priv_key, strlen(flash.flash_ver0.ecc_priv_key) + >>> > 1, (const unsigned char *)CA_DEF_ISSUER_PWD, CA_DEF_ISSUER_PWD_LEN); >>> > mbedtls_md(mbedtls_md_info_from_type(MBEDTLS_MD_SHA256), msg, msg_len, >>> > hash); >>> > mbedtls_pk_sign(&pk, MBEDTLS_MD_SHA256, hash, 0, tmp, (size_t *)&len, >>> > mbedtls_ctr_drbg_random, &ctr_drbg); >>> > >>> > The private key is an ECC key with 384 bit. I have two issue: >>> > >>> > 1) In tmp variable I found the signature, but it is 72 byte, instead >>> > of 96 (384*2/87); >>> > 2) On this signature I try to make a verify, but fails. >>> > >>> > Where I'm wrong? >>> > >>> > Best regards, >>> > Stefano >>> > >>> >>> -- >>> mbed-tls mailing list >>> mbed-tls(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls >>> >> >> IMPORTANT NOTICE: The contents of this email and any attachments are >> confidential and may also be privileged. If you are not the intended >> recipient, please notify the sender immediately and do not disclose the >> contents to any other person, use it for any purpose, or store or copy the >> information in any medium. Thank you. >> > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. >

4 years, 2 months

1
0
0 0

3.0 proposal: remove support for pre-v3 X.509 certificate with extensions

by Manuel Pegourie-Gonnard

Hi all, Version 3 of X.509 was published in 1997 and introduced extensions. However, in the years that followed, some implementations did generate certificates with extensions and a declared version less than 3. Such certs were never compliant and are rejected by default, however we have a compile-time option to no reject them for that reason: MBEDTLS_X509_ALLOW_EXTENSIONS_NON_V3 Since this is 2021 and pre-v3 certificates are unlikely to still be used, we'd like to remove this option in Mbed TLS 3.0. (It would remain in 2.16 and the upcoming 2.x LTS branch.) As usual, more details can be found in the github issue: https://github.com/ARMmbed/mbedtls/issues/4386 If you need this option to still be available in Mbed TLS 3.0, please speak up now, here on on github! Regards, Manuel.

4 years, 2 months

1
0
0 0

Re: [mbed-tls] SSL session cache API in Mbed TLS 3.0

by Jérémy Audiger

Hi Hanno, Regarding your first point, I'm not against having the structure mbedtls_ssl_session as opaque on the application side, at least, it ensures the application is not modifying something that it shouldn't. Having said that, on my side, I access three fields of this structure: * sslContext.state * sslContext.own_cid_len * sslContext.own_cid The first one is used to retrieve the current state, mainly MBEDTLS_SSL_HANDSHAKE_OVER, MBEDTLS_SSL_SERVER_HELLO_VERIFY_REQUEST_SENT. Finally, the match between an incoming LwM2M Client encrypted message using CID and the structure mbedtls_ssl_session is done by accessing own_cid / own_cid_len. But I think this one could be done using mbedtls_ssl_get_peer_cid(). Regards, Jérémy ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Hanno Becker via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Friday, April 16, 2021 06:37 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] SSL session cache API in Mbed TLS 3.0 Hi Mbed TLS enthusiasts, For Mbed TLS 3.0, we're considering to modify the API around SSL sessions and server-side SSL session caches as follows: 1) The mbedtls_ssl_session structure becomes opaque, that is, its layout, fields, size is not part of the API and thus not subject to any stability promises. Instances of mbedtls_ssl_session may only be accessed through public function API. At the time of writing, this is mainly mbedtls_ssl_session_load()/save() for session serialization and deserialization. In particular, user code requiring access to specific fields of mbedtls_ssl_session won't be portable without further adjustments, e.g. the addition of getter functions. If you access fields of mbedtls_ssl_session in your code and would like to retain the ability to do so, now is the time to speak up and let us know about your use case. 2) The SSL session cache API gets modified as proposed in https://github.com/ARMmbed/mbedtls/issues/4333#issuecomment-820297322: int mbedtls_ssl_cache_get( void *data, unsigned char const *session_id, size_t session_id_len, mbedtls_ssl_session *dst_session ); int mbedtls_ssl_cache_set( void *data, unsigned char const *session_id, size_t session_id_len, mbedtls_ssl_session const *session ); In words: The session ID becomes an explicit parameter. This modification is necessary because the present session cache API requires custom implementations to peek into the mbedtls_ssl_session structure, at least to inspect the session ID. With the session ID being added as an explicit parameter, this is no longer necessary. We propose that custom session cache implementations treat mbedtls_ssl_session instances opaquely and only use them through the serialization and deserialization API mbedtls_ssl_session_load()/save(). The reason why the proposed API does not operate on serialized data directly is that this would enforce unnecessary copies. If you are using a custom SSL server-side session cache implementation which accesses fields other than the session ID and which can not be implemented based on session serialization, now is the time to speak up and let us know about your use case. Kind regards, Hanno

4 years, 2 months

2
1
0 0

Re: [mbed-tls] Signing messages with ECDSA

by Gilles Peskine

Hi Stefano, Assuming that the key is in PEM format and that the buffers (hash, tmp) are large enough, I don't see anything wrong in the part of the code you posted. You posted code without error checking. Can you confirm that all functions return 0? mbedtls_pk_sign produces ECDSA signatures in ASN.1 format. The size of the signature can be up to 104 bytes, and is often a few bytes shorter because it consists of numbers in which leading zeros are omitted. Make sure the tmp buffer is large enough. You can use MBEDTLS_ECDSA_MAX_SIG_LEN(384) or MBEDTLS_ECDSA_MAX_LEN (from mbedtls/ecdsa.h) as the signature buffer size. 72 bytes is the maximum size of a signature for a 256-bit key, reached about 25% of the time. Are you sure you're signing with the key you intended? People may be able to help more if you post complete code that we can run on our machine. Best regards, -- Gilles Peskine Mbed TLS developer On 20/04/2021 16:49, stefano664 via mbed-tls wrote: > Hi all, > I have some problems with mbedTLS during ECDSA signing process. > > I followed the example supplied with the source code and write this code: > > mbedtls_pk_init(&pk); > mbedtls_pk_parse_key(&pk, (const unsigned char *) > flash.flash_ver0.ecc_priv_key, strlen(flash.flash_ver0.ecc_priv_key) + > 1, (const unsigned char *)CA_DEF_ISSUER_PWD, CA_DEF_ISSUER_PWD_LEN); > mbedtls_md(mbedtls_md_info_from_type(MBEDTLS_MD_SHA256), msg, msg_len, > hash); > mbedtls_pk_sign(&pk, MBEDTLS_MD_SHA256, hash, 0, tmp, (size_t *)&len, > mbedtls_ctr_drbg_random, &ctr_drbg); > > The private key is an ECC key with 384 bit. I have two issue: > > 1) In tmp variable I found the signature, but it is 72 byte, instead > of 96 (384*2/87); > 2) On this signature I try to make a verify, but fails. > > Where I'm wrong? > > Best regards, > Stefano >

4 years, 2 months

1
0
0 0

Signing messages with ECDSA

by stefano664

Hi all, I have some problems with mbedTLS during ECDSA signing process. I followed the example supplied with the source code and write this code: mbedtls_pk_init(&pk); mbedtls_pk_parse_key(&pk, (const unsigned char *) flash.flash_ver0.ecc_priv_key, strlen(flash.flash_ver0.ecc_priv_key) + 1, (const unsigned char *)CA_DEF_ISSUER_PWD, CA_DEF_ISSUER_PWD_LEN); mbedtls_md(mbedtls_md_info_from_type(MBEDTLS_MD_SHA256), msg, msg_len, hash); mbedtls_pk_sign(&pk, MBEDTLS_MD_SHA256, hash, 0, tmp, (size_t *)&len, mbedtls_ctr_drbg_random, &ctr_drbg); The private key is an ECC key with 384 bit. I have two issue: 1) In tmp variable I found the signature, but it is 72 byte, instead of 96 (384*2/87); 2) On this signature I try to make a verify, but fails. Where I'm wrong? Best regards, Stefano

4 years, 2 months

1
0
0 0

Re: [mbed-tls] TLS serialization

by Manuel Pegourie-Gonnard

Hi Jérémy, Thanks for your question! Indeed, the context (de)serialization feature only support DTLS so far. We've added an enhancement request to our backlog to extend it to TLS: https://github.com/ARMmbed/mbedtls/issues/4340 However, it may take some time before we get to it, as we're currently focused on preparing Mbed TLS 3.0. Also, this enhancement may very well turn out to be more complex that it might look initially: TLS is a reliable stream protocol (as opposed to DTLS which is an unreliable datagram protocol) and there will probably be some precautions to take and corner case to handle in order to make sure the full stream is preserved. If you or anyone else wants to open a PR for that, that would obviously help - though again, I'm afraid we'll have little review bandwidth until the end of June. (More generally, it's always a good idea to coordinate on the list before raising a large or complex PR.) Regards, Manuel. ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Jérémy Audiger via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 12 April 2021 18:39 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] TLS serialization Hi everyone, I'm currently trying to add the ability to serialize / deserialize a TLS security session using these APIs: * mbedtls_ssl_context_load() * mbedtls_ssl_context_save() I'm on TLS Server-side (so not talking about TLS Client here). After digging through the mailing list, I discovered this previous topic: https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/000012.html and this Github repository: https://github.com/dimakuv/mbedtls-psk-example The scenario is the same here: using PSK with ciphersuite MBEDTLS_TLS_PSK_WITH_AES_128_CCM_8 Once the handshake is done, I'm able to serialize the TLS session with the patch attached to this email. After that I'm able to decrypt one incoming packet and encrypt one ongoing packet. So, almost everything is fine. But, when the TLS Server is receiving another message from the TLS Client (message sent in two fragments), the Server is able to decrypt the first fragment but not the second one, getting this error: ssl_msg.c:5475: 0x7f9aa803d288: => read ssl_msg.c:4029: 0x7f9aa803d288: => read record ssl_msg.c:2012: 0x7f9aa803d288: => fetch input ssl_msg.c:2167: 0x7f9aa803d288: in_left: 0, nb_want: 5 ssl_msg.c:2192: 0x7f9aa803d288: in_left: 0, nb_want: 5 ssl_msg.c:2195: 0x7f9aa803d288: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_msg.c:2215: 0x7f9aa803d288: <= fetch input ssl_msg.c:3763: 0x7f9aa803d288: dumping 'input record header' (5 bytes) ssl_msg.c:3763: 0x7f9aa803d288: 0000: 17 03 03 00 41 ....A ssl_msg.c:3765: 0x7f9aa803d288: input record: msgtype = 23, version = [3:3], msglen = 65 ssl_msg.c:2012: 0x7f9aa803d288: => fetch input ssl_msg.c:2167: 0x7f9aa803d288: in_left: 5, nb_want: 70 ssl_msg.c:2192: 0x7f9aa803d288: in_left: 5, nb_want: 70 ssl_msg.c:2195: 0x7f9aa803d288: ssl->f_recv(_timeout)() returned 65 (-0xffffffbf) ssl_msg.c:2215: 0x7f9aa803d288: <= fetch input ssl_msg.c:3874: 0x7f9aa803d288: dumping 'input record from network' (70 bytes) ssl_msg.c:3874: 0x7f9aa803d288: 0000: 17 03 03 00 41 00 00 00 00 00 00 00 03 27 9d 1a ....A........'.. ssl_msg.c:3874: 0x7f9aa803d288: 0010: 50 14 ff e1 14 8c b0 f5 de 06 1c f0 43 5c a0 91 P...........C\.. ssl_msg.c:3874: 0x7f9aa803d288: 0020: 46 23 3e 42 86 ed 3a 48 38 3d e8 b4 05 09 50 ac F#>B..:H8=....P. ssl_msg.c:3874: 0x7f9aa803d288: 0030: 94 6b 9c fb c6 22 7b 46 62 e0 af 08 ab 60 50 3c .k..."{Fb....`P< ssl_msg.c:3874: 0x7f9aa803d288: 0040: 6d c6 c8 7c cb 2c m..|., ssl_msg.c:1301: 0x7f9aa803d288: => decrypt buf ssl_msg.c:1414: 0x7f9aa803d288: dumping 'additional data used for AEAD' (13 bytes) ssl_msg.c:1414: 0x7f9aa803d288: 0000: 00 00 00 00 00 00 00 02 17 03 03 00 31 ............1 ssl_msg.c:1423: 0x7f9aa803d288: dumping 'IV used' (12 bytes) ssl_msg.c:1423: 0x7f9aa803d288: 0000: db 70 01 4b 00 00 00 00 00 00 00 03 .p.K........ ssl_msg.c:1424: 0x7f9aa803d288: dumping 'TAG used' (8 bytes) ssl_msg.c:1424: 0x7f9aa803d288: 0000: 50 3c 6d c6 c8 7c cb 2c P<m..|., ssl_msg.c:1437: 0x7f9aa803d288: mbedtls_cipher_auth_decrypt() returned -25344 (-0x6300) ssl_msg.c:3900: 0x7f9aa803d288: ssl_decrypt_buf() returned -29056 (-0x7180) Between each emission or reception of the fragment, the TLS security context is loaded and saved into a database. The use case here is really interesting, it seems to work well except when I receive or emit a message split into multiple fragments. Something is lost during the session backup. Maybe an interesting thing to add is when I'm loading a TLS session from the database, I'm following these steps: * Load the session into a buffer from the database * Init a security session with mbedtls_ssl_init() and mbedtls_ssl_setup() * Load the session from the buffer with mbedtls_ssl_context_load() Since I'm not an expert of mbed TLS code, I would like to know if someone could help me investigate this issue. TLS serialization/deserialization could be interesting to be part of the mbed TLS library. Regards, Jérémy Audiger

4 years, 2 months

2
1
0 0

3.0 Proposal: remove 3DES ciphersuites

by Manuel Pegourie-Gonnard

Hi all, We'd like to completely remove support for 3DES TLS ciphersuites in Mbed TLS 3.0. Those ciphersuites are vulnerable to the Sweet32 attack and 3DES has been deprecated by NIST. If we remove them from Mbed TLS 3.0, they will remain available in Mbed TLS 2.16 and 2.x, the latter being supported until 3 years after 3.0 has been released. As usual, if for any reason you need support for 3DES TLS ciphersuites in Mbed TLS 3.0, please speak up now and let use know about your use case! More context can be found at https://github.com/ARMmbed/mbedtls/issues/4367 Regards, Manuel.

4 years, 2 months

1
0
0 0

3.0 proposal: remove support for MD2, MD4, RC4, Blowfish and XTEA

by Ronald Cron

Hi, We consider removing the support for MD2, MD4, RC4, Blowfish and XTEA from Mbed TLS 3.0 (but the support will remain in the 2.16 and 2.2x LTS branches for the course of their lifetime). If you use one of those cryptographic primitives and think it should remain in Mbed TLS 3.0, please let us know and explain why. You can find more information in the following GitHub issue: https://github.com/ARMmbed/mbedtls/issues/4084. Best regards, Ronald Cron.

4 years, 2 months

1
0
0 0

SSL session cache API in Mbed TLS 3.0

by Hanno Becker

Hi Mbed TLS enthusiasts, For Mbed TLS 3.0, we're considering to modify the API around SSL sessions and server-side SSL session caches as follows: 1) The mbedtls_ssl_session structure becomes opaque, that is, its layout, fields, size is not part of the API and thus not subject to any stability promises. Instances of mbedtls_ssl_session may only be accessed through public function API. At the time of writing, this is mainly mbedtls_ssl_session_load()/save() for session serialization and deserialization. In particular, user code requiring access to specific fields of mbedtls_ssl_session won't be portable without further adjustments, e.g. the addition of getter functions. If you access fields of mbedtls_ssl_session in your code and would like to retain the ability to do so, now is the time to speak up and let us know about your use case. 2) The SSL session cache API gets modified as proposed in https://github.com/ARMmbed/mbedtls/issues/4333#issuecomment-820297322: int mbedtls_ssl_cache_get( void *data, unsigned char const *session_id, size_t session_id_len, mbedtls_ssl_session *dst_session ); int mbedtls_ssl_cache_set( void *data, unsigned char const *session_id, size_t session_id_len, mbedtls_ssl_session const *session ); In words: The session ID becomes an explicit parameter. This modification is necessary because the present session cache API requires custom implementations to peek into the mbedtls_ssl_session structure, at least to inspect the session ID. With the session ID being added as an explicit parameter, this is no longer necessary. We propose that custom session cache implementations treat mbedtls_ssl_session instances opaquely and only use them through the serialization and deserialization API mbedtls_ssl_session_load()/save(). The reason why the proposed API does not operate on serialized data directly is that this would enforce unnecessary copies. If you are using a custom SSL server-side session cache implementation which accesses fields other than the session ID and which can not be implemented based on session serialization, now is the time to speak up and let us know about your use case. Kind regards, Hanno

4 years, 2 months

1
0
0 0

3.0 proposal: remove support for Truncated HMAC

by Manuel Pegourie-Gonnard

Hi everyone, Truncated HMAC is a TLS extension that was originally created to reduce overhead in constrained environments. Nowadays, CCM-8 ciphersuites are an alternative that's superior both in terms of having even lower overhead and in terms of security. Consequently, recent RFCs have stated that the Truncated HMAC extensions must no longer be used. So, we would like to entirely remove support for this extension from Mbed TLS 3.0. (LTS branches would obviously retain support for it.) If you need support for Truncated HMAC extension in Mbed TLS 3.0, please speak up now! More context and details can be found in this github issue, which can also be used for discussion: https://github.com/ARMmbed/mbedtls/issues/4341 Regards, Manuel.

4 years, 2 months

1
0
0 0

TLS serialization

by Jérémy Audiger

Hi everyone, I'm currently trying to add the ability to serialize / deserialize a TLS security session using these APIs: * mbedtls_ssl_context_load() * mbedtls_ssl_context_save() I'm on TLS Server-side (so not talking about TLS Client here). After digging through the mailing list, I discovered this previous topic: https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/000012.html and this Github repository: https://github.com/dimakuv/mbedtls-psk-example The scenario is the same here: using PSK with ciphersuite MBEDTLS_TLS_PSK_WITH_AES_128_CCM_8 Once the handshake is done, I'm able to serialize the TLS session with the patch attached to this email. After that I'm able to decrypt one incoming packet and encrypt one ongoing packet. So, almost everything is fine. But, when the TLS Server is receiving another message from the TLS Client (message sent in two fragments), the Server is able to decrypt the first fragment but not the second one, getting this error: ssl_msg.c:5475: 0x7f9aa803d288: => read ssl_msg.c:4029: 0x7f9aa803d288: => read record ssl_msg.c:2012: 0x7f9aa803d288: => fetch input ssl_msg.c:2167: 0x7f9aa803d288: in_left: 0, nb_want: 5 ssl_msg.c:2192: 0x7f9aa803d288: in_left: 0, nb_want: 5 ssl_msg.c:2195: 0x7f9aa803d288: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb) ssl_msg.c:2215: 0x7f9aa803d288: <= fetch input ssl_msg.c:3763: 0x7f9aa803d288: dumping 'input record header' (5 bytes) ssl_msg.c:3763: 0x7f9aa803d288: 0000: 17 03 03 00 41 ....A ssl_msg.c:3765: 0x7f9aa803d288: input record: msgtype = 23, version = [3:3], msglen = 65 ssl_msg.c:2012: 0x7f9aa803d288: => fetch input ssl_msg.c:2167: 0x7f9aa803d288: in_left: 5, nb_want: 70 ssl_msg.c:2192: 0x7f9aa803d288: in_left: 5, nb_want: 70 ssl_msg.c:2195: 0x7f9aa803d288: ssl->f_recv(_timeout)() returned 65 (-0xffffffbf) ssl_msg.c:2215: 0x7f9aa803d288: <= fetch input ssl_msg.c:3874: 0x7f9aa803d288: dumping 'input record from network' (70 bytes) ssl_msg.c:3874: 0x7f9aa803d288: 0000: 17 03 03 00 41 00 00 00 00 00 00 00 03 27 9d 1a ....A........'.. ssl_msg.c:3874: 0x7f9aa803d288: 0010: 50 14 ff e1 14 8c b0 f5 de 06 1c f0 43 5c a0 91 P...........C\.. ssl_msg.c:3874: 0x7f9aa803d288: 0020: 46 23 3e 42 86 ed 3a 48 38 3d e8 b4 05 09 50 ac F#>B..:H8=....P. ssl_msg.c:3874: 0x7f9aa803d288: 0030: 94 6b 9c fb c6 22 7b 46 62 e0 af 08 ab 60 50 3c .k..."{Fb....`P< ssl_msg.c:3874: 0x7f9aa803d288: 0040: 6d c6 c8 7c cb 2c m..|., ssl_msg.c:1301: 0x7f9aa803d288: => decrypt buf ssl_msg.c:1414: 0x7f9aa803d288: dumping 'additional data used for AEAD' (13 bytes) ssl_msg.c:1414: 0x7f9aa803d288: 0000: 00 00 00 00 00 00 00 02 17 03 03 00 31 ............1 ssl_msg.c:1423: 0x7f9aa803d288: dumping 'IV used' (12 bytes) ssl_msg.c:1423: 0x7f9aa803d288: 0000: db 70 01 4b 00 00 00 00 00 00 00 03 .p.K........ ssl_msg.c:1424: 0x7f9aa803d288: dumping 'TAG used' (8 bytes) ssl_msg.c:1424: 0x7f9aa803d288: 0000: 50 3c 6d c6 c8 7c cb 2c P<m..|., ssl_msg.c:1437: 0x7f9aa803d288: mbedtls_cipher_auth_decrypt() returned -25344 (-0x6300) ssl_msg.c:3900: 0x7f9aa803d288: ssl_decrypt_buf() returned -29056 (-0x7180) Between each emission or reception of the fragment, the TLS security context is loaded and saved into a database. The use case here is really interesting, it seems to work well except when I receive or emit a message split into multiple fragments. Something is lost during the session backup. Maybe an interesting thing to add is when I'm loading a TLS session from the database, I'm following these steps: * Load the session into a buffer from the database * Init a security session with mbedtls_ssl_init() and mbedtls_ssl_setup() * Load the session from the buffer with mbedtls_ssl_context_load() Since I'm not an expert of mbed TLS code, I would like to know if someone could help me investigate this issue. TLS serialization/deserialization could be interesting to be part of the mbed TLS library. Regards, Jérémy Audiger

4 years, 2 months

1
0
0 0

3.0 proposal: remove support for TLS 1.0, TLS 1.1 and DTLS 1.0

by Manuel Pegourie-Gonnard

Hi everyone, The IETF has recently published RFC 8996, which formally deprecates TLS 1.0, TLS 1.1 and DTLS 1.0 (there is no DTLS 1.1). One of the stated goals of the RFC is to empower maintainers of (D)TLS stacks to remove them from their code base, reducing the maintenance cost and the attack surface at the same time. This RFC comes right during the time we're preparing a new major version, which is the only time we allow ourselves to remove features. We'd like to take advantage of this opportunity by entirely removing support for TLS 1.0, TLS 1.1 and DTLS 1.0 in Mbed TLS 3.0. (They would obviously stay in our long-term support branches.) If you find yourself needing support for these versions in Mbed TLS 3.0, now is the time to speak up! More details can be found in the following github issue: https://github.com/ARMmbed/mbedtls/issues/4286 Feel free to discuss this issue on the list or on github, whatever's more convenient for you. Best regards, Manuel.

4 years, 2 months

1
0
0 0

Mbed TLS 3.0 branching

by Dave Rodgman

Hello Mbed TLS users, As previously announced, we are going to switch the focus of Mbed TLS development onto the upcoming 3.0 release. * We have created the development_2.x branch, currently aligned with the tip of development * For the next two weeks, we will keep development and development_2.x in sync (daily) * On April 22, we will merge development_3.0 into development, and remove development_3.0 This means that after April 22: * development will contain API-breaking changes * new features will not normally be back-ported to development_2.x (unless there is a compelling reason to do so) * relevant bugfixes will be backported as normal Impact for users: * users of development should consider whether they should switch to using development_2.x * authors of PRs requiring backports may require an additional backport to development_2.x Regards Dave Rodgman

4 years, 2 months

1
0
0 0

3.0 proposal: remove MBEDTLS_CHECK_PARAMS

by Gilles Peskine

Hello, I propose to remove the MBEDTLS_CHECK_PARAMS feature from Mbed TLS 3.0. (As with everything else, it will of course remain in the 2.16 and 2.2x long-time support branches.) If you are using MBEDTLS_CHECK_PARAMS and you think it should remain, please let us know and explain why. If you are not using this feature, I personally think that you're making the right choice. But if you're curious what it is, you can read the documentation or my description in https://github.com/ARMmbed/mbedtls/issues/4313 . -- Gilles Peskine Mbed TLS developer

4 years, 2 months

1
0
0 0

Re: [mbed-tls] mbedtls_hmac_drbg_seed fails, returns MBEDTLS_ERR_ENTROPY_SOURCE_FAILED

by Gilles Peskine

Hi Jeff, It looks like you're using an old version of Mbed TLS. mbedtls_hmac_drbg_seed used to set ctx->entropy_len to entropy_len * 3 / 2, but this changed (https://github.com/ARMmbed/mbed-crypto/pull/238) to making a call to mbedtls_entropy_func for entropy_len and then one again for entropy_len / 2, precisely to avoid the scenario you're describing where the HMAC_DRBG module would request more entropy than the entropy can deliver in a single call. Please upgrade to the latest release of Mbed TLS, or the latest 2.16 release if you want a long-time support branch. The version you're using is old and has known vulnerabilities. -- Gilles Peskine Mbed TLS developer On 06/04/2021 13:59, Thompson, Jeff via mbed-tls wrote: > > ï¿½ > > The call flow is mbedtls_hmac_drbg -> mbedtls_hmac_drbg_reseed -> > mbedtls_entropy_func where the parameter, len, is 48 and > MBEDTLS_ENTROPY_BLOCK_SIZE is 32. I see that mbedtls_hmac_drbg_seed > sets ï¿½ctx->entropy_len = entropy_len * 3 / 2, which explains the size > difference. Iï¿½ve probably mis-configured (see attached) in order to > use TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA, because other ciphers take too > long. > > ï¿½ > > *Jeff Thompson*ï¿½| ï¿½Senior Electrical Engineer-Firmware > +1 704 752 6513 x1394 > www.invue.com <www.invue.com> > > ï¿½ > >

4 years, 2 months

1
0
0 0

mbedtls_hmac_drbg_seed fails, returns MBEDTLS_ERR_ENTROPY_SOURCE_FAILED

by Thompson, Jeff

The call flow is mbedtls_hmac_drbg -> mbedtls_hmac_drbg_reseed -> mbedtls_entropy_func where the parameter, len, is 48 and MBEDTLS_ENTROPY_BLOCK_SIZE is 32. I see that mbedtls_hmac_drbg_seed sets ctx->entropy_len = entropy_len * 3 / 2, which explains the size difference. I've probably mis-configured (see attached) in order to use TLS-ECDHE-RSA-WITH-AES-128-CBC-SHA, because other ciphers take too long. Jeff Thompson | Senior Electrical Engineer-Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D72ABA.56C4A310]

4 years, 2 months

1
0
0 0

Re: [mbed-tls] Mbed TLS mbedtls_ssl_config (struct) Question

by Manuel Pegourie-Gonnard

Hi Keith, Those are good questions, and the short answer is everything should work in a multi-threaded environment if Mbed TLS was built with threading support (for example, enabling MBEDTLS_THREADING_C and MBEDTLS_THREADING_PTHREAD in config.h). Now for some more details: regarding mbedtls_ssl_config, it is indeed treated as read-only by all function in the SSL/TLS module, except of course those functions that are explicitly meant to modify it (those whose name starts with mbedtls_ssl_conf_). So, if you set it up in the main thread and then use it in other threads, everything will be fine regarding the top-level structure itself (for sub-structures see below), regardless of whether threading support is enabled. For the DRBG contexts, you're right that each time we draw from them, they need to update their state. However, this is protected by a mutex if threading support was enabled at compile-time. A similar thing goes for private keys : RSA private keys are protected by a mutex if threading support is enabled (using them mutates state used for side-channel countermeasures), and ECDSA private keys are safe too. X.509 structures are always treated as read-only. Regarding documentation: we did recently expand the documentation on DRBGs: https://github.com/ARMmbed/mbedtls/commit/f305d92480c81c6eb02934a4e1af58152… Regarding SSL, I agree this should be better documented. If you'd like to open a PR to add documentation that would have answered your question, that would be very welcome. Regards, Manuel ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Keith Cancel via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: 02 April 2021 06:43 To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] Mbed TLS mbedtls_ssl_config (struct) Question Hello, I hope this a simple question regarding mbedtls_ssl_config. So it seems this structure is meant to be shared/used for multiple connections. However, if I have multiple threads is it treated as a read only structure by all the library code, or does it update some state at times? Similar thing regarding the mbedtls_x509_crt struct and mbedtls_ctr_drbg_context which also seem to be added to the config when I setup the config. I was hoping that once set I don’t have to worry about any mutexs/locks being used by the library under the hood. Mainly, that once the configuration is set in the main thread it state is never updated again. What made me curious about this is the fact the RNG seems to be part of the configuration and a CPRNG will generally have state that needs to change. Moreover, I can’t really find a clear answer looking at the docs. Thanks, Keith Cancel -- mbed-tls mailing list mbed-tls(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls

4 years, 2 months

1
0
0 0

Mbed TLS mbedtls_ssl_config (struct) Question

by Keith Cancel

Hello, I hope this a simple question regarding mbedtls_ssl_config. So it seems this structure is meant to be shared/used for multiple connections. However, if I have multiple threads is it treated as a read only structure by all the library code, or does it update some state at times? Similar thing regarding the mbedtls_x509_crt struct and mbedtls_ctr_drbg_context which also seem to be added to the config when I setup the config. I was hoping that once set I don’t have to worry about any mutexs/locks being used by the library under the hood. Mainly, that once the configuration is set in the main thread it state is never updated again. What made me curious about this is the fact the RNG seems to be part of the configuration and a CPRNG will generally have state that needs to change. Moreover, I can’t really find a clear answer looking at the docs. Thanks, Keith Cancel

4 years, 2 months

1
0
0 0

MbedTLS handshark faild "The certificate is not correctly signed bythe trusted CA"

by chen

Hello, I run a client that has been ported MbedTLS, but the client connect server faild. I check the debug log, the end client state is 15. In the client state 3, the client receive only one certificate from server, and the log printing "Certificate verification flags 8". Here are part of logs: ..\MbedTLS\library\ssl_tls.c:4232: dumping 'input record from network' (4467 bytes) ..\MbedTLS\library\ssl_tls.c:4232: 0000: 16 03 03 11 6e 0b 00 11 6a 00 11 67 00 05 c2 30 ....n...j..g...0 ..\MbedTLS\library\ssl_tls.c:4232: 0010: -------- omit some network input data -------- ..\MbedTLS\library\ssl_tls.c:4232: 0ff0: 38 a0 36 a0 34 86 32 68 74 74 70 3a 2f 2f 63 72 8.6.4.2http://cr ..\MbedTLS\library\ssl_tls.c:3624: handshake message: msglen = 4462, type = 11, hslen = 4462 ..\MbedTLS\library\ssl_tls.c:4385: <= read record ..\MbedTLS\library\ssl_tls.c:5606: peer certificate #1: ..\MbedTLS\library\ssl_tls.c:5606: cert. version : 3 ..\MbedTLS\library\ssl_tls.c:5606: serial number : F0:57:5F:65:80:A9:70:B4:F9:8E:42:91:AE:D0:70:27 ..\MbedTLS\library\ssl_tls.c:5606: issuer name : C=GB, ST=Greater Manchester, L=Salford, O=Sectigo Limited, CN=Sectigo RSA Domain Validation Secure Server CA ..\MbedTLS\library\ssl_tls.c:5606: subject name : CN=*.xxxxxxxx.com ..\MbedTLS\library\ssl_tls.c:5606: issued on : 2020-06-01 00:00:00 ..\MbedTLS\library\ssl_tls.c:5606: expires on : 2021-05-26 23:59:59 ..\MbedTLS\library\ssl_tls.c:5606: signed using : RSA with SHA-256 ..\MbedTLS\library\ssl_tls.c:5606: RSA key size : 2048 bits ..\MbedTLS\library\ssl_tls.c:5606: basic constraints : CA=false ..\MbedTLS\library\ssl_tls.c:5606: subject alt name : *.xxxxxxxx.com, xxxxxxxx.com ..\MbedTLS\library\ssl_tls.c:5606: key usage : Digital Signature, Key Encipherment ..\MbedTLS\library\ssl_tls.c:5606: ext key usage : TLS Web Server Authentication, TLS Web Client Authentication ..\MbedTLS\library\ssl_tls.c:5606: value of 'crt->rsa.N' (2048 bits) is: ..\MbedTLS\library\ssl_tls.c:5606: af b7 73 1a f9 8a 2d 5e a2 e8 0f fd 89 5d 60 1d ..\MbedTLS\library\ssl_tls.c:5606: -------- omit some bits -------- ..\MbedTLS\library\ssl_tls.c:5606: e6 8e f8 3e ed ec 8e dd ec 46 48 85 9a b4 c8 71 ..\MbedTLS\library\ssl_tls.c:5606: value of 'crt->rsa.E' (17 bits) is: ..\MbedTLS\library\ssl_tls.c:5606: 01 00 01 ..\MbedTLS\library\ssl_tls.c:5757: x509_verify_cert() returned -9984 (-0x2700) ..\MbedTLS\library\ssl_tls.c:5851: ! Certificate verification flags 8 ..\MbedTLS\library\ssl_tls.c:5863: <= parse certificate At the client side, I download certificate of server, and get CA and root CA base on this certificate. Loading any one of these certificates into the client can't connect server. I did a test with another server. The different of the handshark is that the server issued two certificates, one is server's cert and another is CA cert. Loading CA or root CA into the client both can connect server successfully. problems: 1. Must the server send CA certificate in handshake phase? 2. The client holds CA certificate, dose MbedTLS client support downloading CA base on server's certificate? 3. In the source code, the certificate chain only contains the certificate issued by the server during handshake, not the CA certificate downloaded by the client according to the server certificate? Thank you very much for the answers. Best regards, berry chen

4 years, 3 months

1
0
0 0

Re: [mbed-tls] C/assembly option

by Gilles Peskine

Hi Raoul, Do I understand correctly that the problem with Mbed TLS as it is now is that you need MBEDTLS_HAVE_ASM enabled for AESNI and disabled for bignum? Would you want even more granularity? In principle, we could create a new compile-time option MBEDTLS_MPI_ASM, defaulting to what it does now (enabled if MBEDTLS_HAVE_ASM if the platform is one of the known ones) but overridable in either direction. However I don't like it much because we're trying to cut down on compilation options to reduce the maintenance burden: each compilation option adds complexity which makes it harder to understand all interactions between different parts of the library, and adds some testing burden. Symmetric and asymmetric crypto are mostly decoupled, so this one wouldn't be too bad, but it all adds up. In the long term, I expect that the different cryptographic algorithms will become more decoupled, with a possibility to treat each one as a black box that could be implemented by a hardware driver, and with a uniform mechanism to select drivers (or maybe they should be called engines). The evolution of the crypto part of the library to PSA is going in this direction. But we aren't there yet. Sorry that I don't have a more satisfying answer here. -- Gilles Peskine Mbed TLS developer On 31/03/2021 09:13, Raoul Strackx via mbed-tls wrote: > Hi all, > > We have a product that requires very strong security measures. When > compiling the mbedtls library, we face the following issue: Compiling C > code with LVI-mitigations is often much faster than relying on automatic > LVI mitigations on assembly code. The MPI functions are a good example > where we wish to rely on C source code. For other functions, we need to > rely on assembly code in order to mitigate other vulnerabilities (e.g., > we require AESNI assembly instructions over C implementations of AES). > Currently there isn't an option to choose between C/assembly per function. > > What would be an acceptable solution for this? > > greetings, > > Raoul > > >

4 years, 3 months

1
0
0 0

Minimum development environment: 2021 edition

by Gilles Peskine

Hello, In a nutshell: 1. Must Mbed TLS support Python 3.4 to configure and test, or can 3.6 be enough? 2. Must the supplied CMake scripts support 2.8.12.2, or can 3.5.2 be enough? This thread is about minimum tool versions to configure, build and test Mbed TLS (excluding TLS interoperability testing and some maintainer scripts) on Linux and similar (Unix-like) platforms. (This is not about the set of platforms where Mbed TLS will _run_, which is as close to “anything with CHAR_BIT==8 and sizeof(size_t) >= 4” as we can make it.) Our general guideline is that Mbed TLS should build out of the box on supported versions of major desktop and server operating systems. In practice, this has tended to mean supporting tool versions from RHEL/CentOS, SLES and Ubuntu LTS releases (but not necessarily extended security maintenance releases). Last year (https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/thread.html) we concluded that we should support the following minimum versions, which will remain supported in the Mbed TLS 2.16 long-time support (LTS) branch: clang 3.8 cmake 2.8.12.2 gcc 4.4 make 3.81 python 3.4 (in 2.16: only to build the unit tests, not to configure) Since then, RHEL 6 and Ubuntu 16.04 have reached their end of life, the CentOS world has changed considerably. Looking at maintained platforms after April 2021 (https://github.com/ARMmbed/mbedtls/issues/2896#issuecomment-603471273), our current goal for the upcoming Mbed TLS 2.x LTS (last release before 3.0) is: clang 6.0 cmake 2.8.12.2 (or 3.5.2? or 3.10.2?) gcc 4.8 make 3.82 python 3.6 (or 3.4.10?) Regarding Python: is there any demand for supporting Python versions older than 3.6? Python 3 is required to fine-tune the library configuration (it is not needed if you use the default config.h or a handwritten one) and build the unit tests. Regarding CMake: it is increasingly problematic for us to support CMake 2.8.12, which is only required for RHEL 7: other distributions under consideration have at least CMake 3.5. There is an ongoing effort to improve our CMake scripts to make it easier to integrate Mbed TLS into a larger project, but it is difficult to preserve backward compatibility with 2.8.12. Would it be acceptable to require CMake >= 3.5? CMake >= 3.10.2? If you have any constraints that are not captured here or if you have an opinion regarding Python and CMake versions, please let us know quickly. -- Gilles Peskine Mbed TLS developer

4 years, 3 months

1
0
0 0

C/assembly option

by Raoul Strackx

Hi all, We have a product that requires very strong security measures. When compiling the mbedtls library, we face the following issue: Compiling C code with LVI-mitigations is often much faster than relying on automatic LVI mitigations on assembly code. The MPI functions are a good example where we wish to rely on C source code. For other functions, we need to rely on assembly code in order to mitigate other vulnerabilities (e.g., we require AESNI assembly instructions over C implementations of AES). Currently there isn't an option to choose between C/assembly per function. What would be an acceptable solution for this? greetings, Raoul

4 years, 3 months

1
0
0 0

Mbed TLS releases: 2.26.0, 2.16.10 and 2.7.19

by Dave Rodgman

Hi Mbed TLS users, We have released Mbed TLS versions 2.7.19, 2.16.10 and 2.26.0. These releases of Mbed TLS address several security issues, provide bug fixes, and bring other minor changes. Full details are available in the release notes (https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.26.0, https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.16.10, https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.7.19). We recommend all users to consider whether they are impacted, and to upgrade appropriately. Please note that there will be no further releases on the 2.7 branch, as this is now out of the three year support period. Dave Rodgman

4 years, 3 months

1
0
0 0

OCSP

by Giuseppe Modugno

Is there any support for OCSP stapling in mbedTLS? Is there any roadmap for implementing it?

4 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls