- mbed-tls - lists.trustedfirmware.org

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

5 years, 1 month

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.

5 years, 1 month

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

5 years, 1 month

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

5 years, 1 month

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> > > ï¿½ > >

5 years, 1 month

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]

5 years, 1 month

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

5 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

5 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

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

5 years, 2 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls