- mbed-tls - lists.trustedfirmware.org

by Dave Rodgman

Hi, Today we are switching our branches around, so that the development branch focuses on Mbed TLS 3.0, to be released mid-year. This will include API-breaking changes. 2.x development work will continue on the development_2.x branch. After merging development_3.0 onto development, the development_3.0 branch will be removed. There is no change to the process for submitting PRs: new PRs should continue to target development, with backports to 2.x and 2.16 as needed. (The exception would be a bug-fix that only affects older branches, which would only need ports to the affected branches and not to development). As part of the 3.0 work, we are looking at various things that can be removed from the library. For some of these, we’ve notified the mailing list – please let us know in the next week if you have a good reason for retaining the feature in question. - Remove support for TLS 1.0, TLS 1.1 and DTLS 1.0 https://github.com/ARMmbed/mbedtls/issues/4286 - Remove support for the "Truncated HMAC" (D)TLS extension https://github.com/ARMmbed/mbedtls/issues/4341 - Remove support for 3DES ciphersuites in (D)TLS https://github.com/ARMmbed/mbedtls/issues/4367 - Remove support for RC4, Blowfish, XTEA, MD2 and MD4 https://github.com/ARMmbed/mbedtls/issues/4084 - Remove support for pre-v3 X.509 certificates with extensions https://github.com/ARMmbed/mbedtls/issues/4386 - Remove the RSA key mutex https://github.com/ARMmbed/mbedtls/issues/4124 - Remove MBEDTLS_CHECK_PARAMS https://github.com/ARMmbed/mbedtls/issues/4313 - 3.0 and 2.x :- Minimum development environment: is it OK to require Python >= 3.6 and/or CMake >= 3.5.2? https://lists.trustedfirmware.org/pipermail/mbed-tls/2021-March/000319.html Dave Rodgman

4 years, 1 month

1
0
0 0

Removal of generated source and build files from the development branch

by Gilles Peskine

Hello, A number of files in the Mbed TLS source tree are automatically generated from other files, with a content that does not depend on the platform or configuration. We are considering removing the generated files from the development branch in Git, at least during the work towards Mbed TLS 3.0. This would affect at least the development branch until the 3.0 release, and may affect the development_2.x branch and the development branch after the 3.0 release. Long-time support branches and official releases will continue to have these source files in the Git tree. The reason to remove the generated files is to facilitate development, especially with the restructuring that is happening as we prepare a new major version of the library. This is an experimental change; depending on how effective it is, we may or may not wish to restore the generated files on the development branch when 3.0 stabilizes. It's also still possible that we will not go ahead with this change, depending on the impact on our CI and on the feedback we receive. The affected files are: * Two library source files: library/error.c and library/version_features.c. * Parts of some test programs: programs/test/query_config.c and programs/psa/psa_constant_names_generated.c. * The Visual Studio project files. * Some unit test data files. What does this change for you? **If you were using a long-time support branch or an official release**: no change. **If you were using the supplied GNU Makefile**: there should be no effective change. **If you were using CMake, Visual Studio or custom build scripts** on the development branch: Perl (>=5.8) will be required to generate some library sources and to generate the Visual Studio project files. Python (>=3.4) was already required to run config.py and to build the unit tests. Note that the generated files are independent of the Mbed TLS configuration, so if your deployment has a pre-configuration step, you can generate the files at this step: no new tool is required after the library is configured. The ongoing work (not complete yet as I write) is at https://github.com/ARMmbed/mbedtls/pull/4395 if you want to see what this change means concretely. We are aware that the additional dependencies are a burden in some environments, which is why we will definitely not change anything to releases or to current and future long-time support branches. If you are building Mbed TLS from the development branch and this change affects you, please let us know what constraints apply to your environment. Best regards, -- Gilles Peskine Mbed TLS developer

4 years, 1 month

1
0
0 0

Re: [mbed-tls] Uninitialized variable in rsa_prepare_blinding

by Gilles Peskine

Hello, The macro MBEDTLS_MPI_CHK sets ret, so this particular case is safe. That being said, we do have a hygiene rule to initialize ret variables, to avoid accidentally having uninitialized variables in edge cases. I'll file an issue to fix those. Thanks for reaching out! -- Gilles Peskine Mbed TLS developer On 21/04/2021 17:33, momo 19 via mbed-tls wrote: > 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 > <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, 1 month

1
0
0 0

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

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, 1 month

2
1
0 0

2025

2024

2023

2022

2021

2020

mbed-tls