- mbed-tls - lists.trustedfirmware.org

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.

3 years, 5 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

3 years, 5 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 >

3 years, 5 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

3 years, 5 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

3 years, 5 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.

3 years, 5 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.

3 years, 5 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

3 years, 5 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.

3 years, 5 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

3 years, 5 months

1
0
0 0

2024

2023

2022

2021

2020

mbed-tls