- mbed-tls - lists.trustedfirmware.org

by LockSafe

Hi. I have posted an issue I am having with the use of mbedTLS with ESP8266 SDK (it is freeRTOS based), I have posted my explanation in the link below, then their support asked me to send new questions to this email. If you have any doubt regarding my tests, or if you want I make more different tests, please don't hesitate do ask me. https://forums.mbed.com/t/mbedtls-on-esp8266-sdk-memory-issue/7913 Regards. <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…> Livre de vírus. www.avg.com <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_cam…>. <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

5 years

1
0
0 0

Plans for Mbed TLS 3.0

by Manuel Pegourie-Gonnard

Hi all, In the next few months we'll be preparing version 3.0 of Mbed TLS (with a goal of releasing in the 3rd quarter of calendar year 2020, see our roadmap [1]). [1]: https://developer.trustedfirmware.org/w/mbed-tls/roadmap/ We've been maintaining full API compatibility since Mbed TLS 2.0.0 was released in July of 2015, so this will be our first chance in 5 years to clean up any API that we've found not to be entirely satisfactory, or no longer needed. This is the first in a series of threads discussing what we would like to do in Mbed TLS 3.0 and how (or what we should rather postpone or not do at all). It will present the high-level goals and list some items as examples. Specific items that deserve further discussion (either to decide whether to include them in 3.0, or refine their scope or meaning) will be discussed each in their own thread. Clean up the code by removing old things ---------------------------------------- This facilitates maintenance and testing. Examples: - Remove support for SSL 3.0 and other deprecated protocol options. (But keep support for old crypto that could be useful for data at rest.) - Remove API functions that have been superseded. Improve existing APIs, behaviours, and defaults ----------------------------------------------- This is mainly small things we just couldn't do in the 2.x line due to our compatibility rules. Examples: - Upgrade the default TLS config to only offer (D)TLS 1.2 with forward-secure key exchanges and AEAD ciphers. - Add the 'const' qualifier to various arguments of existing APIs. - Add size arguments to existing APIs that lack such arguments. Reduce the surface of the public API ------------------------------------ This makes it easier to evolve the library while maintaining API compatibility, and also makes testing easier. Examples: - Forbid direct access to members of most (all?) structures. - Define more clearly which APIs are internal and forbid access to them. - Move some non-core modules that are only useful for examples out of the library (for example, certs.s). Prepare the migration to PSA Crypto ----------------------------------- Currently Mbed TLS consists of three libraries: SSL/(D)TLS, X.509, and Crypto. Furthermore, currently Crypto provides both the long-standing `mbedtls_` APIs and the new PSA Crypto APIs, and the TLS and X.509 libraries still largely rely on the `mbedtls_` APIs, as does probably a large amount of external code. Ultimately, we want to move to place where TLS and X.509 only rely on the PSA Crypto API (whose reference implementation will be independent and longer part of Mbed TLS), and where nobody uses the legacy `mbedtls_` APIs any more. But that's a goal for Mbed TLS 4.0. In the meantime, Mbed TLS 3.0 should pave the way for this. The most important thing we want to do in 3.0 is to make most of the low-level crypto modules internal, and only keep the high-level crypto modules to ease the migration for existing users of the `mbedtls_` crypto APIs. Concretely, this would mean for example that the `mbedtls_aes_` functions and types would no longer be part of the API, but using AES via the `mbedtls_cipher_` APIs would still be supported for existing users until Mbed TLS 4.0 - and of course using AES via the PSA Crypto API is the way forward. As this is a vast and complex topic, there will be a specific thread on where exactly we can and would like to draw the line of which crypto APIs are becoming private in Mbed TLS 3.0 and which are maintained until Mbed TLS 4.0 to ease migration. Note: this strongly overlaps with the previous section (reduce the surface of the public API), but the two are still distinct as they're guided by different incentives: general maintainability vs supporting a specific migration. I hope this email starts to clarify what Mbed TLS 3.0 should look like. Feel free to ask questions if anything's not clear, and again, there will be follow-up threads in the coming days and week to discuss specific aspects in more details. Best regards, Manuel (Mbed TLS developer)

5 years

1
0
0 0

Re: [mbed-tls] Static Memory allocation Buffer Size for DTLS #3146

by Manuel Pegourie-Gonnard

Hi Roshini, [please always repy to the list, this allows other people to help as well] > Thanks for your reply. >I am running into one weird issue in memory allocation part. Before moving to the issue, let me explain my configuration macros. > MBEDTLS_SSL_MAX_CONTENT_LEN - Default value > I have enabled platform memory macros > > I have allocated heap memory of around 60KB, which I though is sufficient for DTLS. > I am using ecc based certificates. > And also my application contains CoAP secured using DTLS. > The issue is - > 1. I am sending coap request and I successfully obtain the response also. > I continue the above step for 3 times. 3rd time I am observing the debug message - "ssl_srv.c:3808: |1| mbedtls_ecdh_calc_secret() returned -16 (-0x0010)". > The return code corresponds to memory allocation failure in BIGNUM. > To investigate further, I have customized my calloc function to print the function name - from which allocation failure is done. > I can see the memory allocation failure happened at API "mbedtls_mpi_grow". > > Further, I have increased the heap memory. But still issue is reproducing after certain number of iterations. > > Do you need to change any configuration setting? Not sure why this is happening? I am facing this issue for past 1 week. > It would be really helpful if you can guide me in this issue. If the connection is succeeding the first few times, and failing after a number of times with an out-of-memory message (and the larger the heap, the longer it goes before failing), to me this suggests two possible causes: 1. There could be a memory leak somewhere, in Mbed TLS or in other code used by your application. We do our best to avoid those in Mbed TLS, so I'd like to hope it's unlikely there is a leak in Mbed TLS, but it can't be completely excluded. If the core issue is a memory leak, it could also be in other parts of the code used by your application. One way to check for this would be to print out the current state of the allocator after each successful connection, and check if there is more memory still in use after each connection than after the previous connection. 2. Alternatively, if there is no leak, it could be that the heap is getting so fragmented that the allocator can't find enough consecutive space. Given that the failure happens in `mpi_grow()` which usually makes rather small allocations, that's probably not likely the issue here, but I thought I'd mention it for completeness. Regards, Manuel.

5 years

1
0
0 0

Re: [mbed-tls] Allowing unsupported extensions in X.509 certificates

by Gilles Peskine

On 03/04/2020 10:11, Hanno Becker via mbed-tls wrote: > Hi Lev, > > I believe that this kind of functionality could be implemented on top > of the existing > verify-with-callback API `mbedtls_x509_crt_verify_with_cb()`. More > precisely, > you can enable `MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION` > to ignore unknown extensions initially, and then chekc them yourself > in the > verification callback by manually > traversing `mbedtls_x509_crt::v3_ext`. If you detect > an extension you cannot make sense of and which is marked critical, > you can modify the > verification flags. > > Would that work for you, in principle? Note, though, that this would > work at the level > of verification, not parsing, which might or might not be acceptable. That's a possibility, but it's not very nice. It would be nicer if the library provided the extensions in a list, or provided an easy way to traverse them, which is the solution I'm currently leaning towards. > > In this regard you might also be interested in knowing about a > significant rewrite > of CRT parsing on the `baremetal` branch. The main difference is that > the X.509 CRT > structure has been stripped down to no longer make use of dynamically > allocated > memory but instead only provide pointers to the various fields in the > certificate. > In the case of dynamic-length fields such as the Subject or Issuer > names, but also > the extension list, inspection shall be done through a newline > introduced ASN.1 > parsing function > > int mbedtls_asn1_traverse_sequence_of( > unsigned char **p, > const unsigned char *end, > uint8_t tag_must_mask, uint8_t tag_must_val, > uint8_t tag_may_mask, uint8_t tag_may_val, > int (*cb)( void *ctx, int tag, > unsigned char* start, size_t len ), > void *ctx ); > > https://github.com/ARMmbed/mbedtls/blob/baremetal/include/mbedtls/asn1.h#L3… > > This function traverses an ASN.1 sequence and triggers a callback for > each item found. > This functionality could be used to perform the extension traversal in > the verification callback > or directly after parsing. > > Which extensions are you interested in, particularly, by the way? If > it is a standardized > extension, feel free to add support for it under a new compile-time > feature flag and > file a PR to add it. We do have to balance code size against the proliferation of compile-time options. A compile-time option dedicated for a specific extension is relatively easy to test (like we test the library with/without each cryptographic algorithm). But we should do this in a way that would work well if each extension is gated by a compile-time option, so let's please discuss the design first. -- Gilles Peskine Mbed TLS developer > > Cheers, > Hanno > ------------------------------------------------------------------------ > *From:* mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on > behalf of Lev Stipakov via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> > *Sent:* Friday, April 3, 2020 8:32 AM > *To:* mbed-tls(a)lists.trustedfirmware.org > <mbed-tls(a)lists.trustedfirmware.org> > *Subject:* Re: [mbed-tls] Allowing unsupported extensions in X.509 > certificates > > Hi, > > I am not too much into mbedTLS design and not sure if this would make > sense, > but what about if we introduce an API to let client decide, what to do > with unknown extensions? > > Let's provide a way for a client to specify a callback > > typedef int (*mbedtls_x509_crt_unsupported_extension_cb_t)( > const mbedtls_asn1_buf *oid ); > > which could be an argument to a new method > > int mbedtls_x509_crt_parse_with_ext_cb( mbedtls_x509_crt *chain, > const unsigned char *buf, > size_t buflen, > > mbedtls_x509_crt_unsupported_extension_cb_t f_ext_cb ); > > > which is called when parser encounters unsupported extension: > > /* > * Detect supported extensions > */ > ret = mbedtls_oid_get_x509_ext_type( &extn_oid, &ext_type ); > if( ret != 0 ) > { > /* No parser found, skip extension */ > *p = end_ext_octet; > > if( is_critical ) > { > /* Data is marked as critical: ask client what to do */ > if( f_ext_cb != NULL ) > { > ret = f_ext_cb( &extn_oid ); > } > > /* Client is OK with unsupported critical extension, continue */ > if( ret == 0 ) > continue; > > return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + > MBEDTLS_ERR_ASN1_UNEXPECTED_TAG ); > } > > continue; > } > > This would allow us to deprecate > MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION - > those clients which want to allow all extensions could pass a callback > which always returns 0. > > What do you think? > > -- > -Lev > -- > 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.

5 years

1
0
0 0

Re: [mbed-tls] How to generate a certificate request with X.509 OID MBEDTLS_OID_SERVER_AUTH

by Hanno Becker

Hi Thomas, Could you share the relevant piece of the code and perhaps the raw CSR data it generates? >From what you write, it looks like you have called `mbedtls_x509write_csr_set_extension()` with OID `MBEDTLS_OID_SERVER_AUTH`, which isn't quite right: `mbedtls_x509write_csr_set_extension()` registers a single extension, and the TLS Web Server Authentication usage is one usage constraint within the ExtendedKeyUsage extension. I'd therefore expect that you have to call `mbedtls_x509write_csr_set_extension()` with `MBEDTLS_OID_EXTENDED_KEY_USAGE` passing it the raw ASN.1 content of the ExtendedKeyUsage extension, part of which is `MBEDTLS_OID_SERVER_AUTH`. To my knowledge, there is currently no API within Mbed TLS which helps you writing this ASN.1 content from a list of usage constraints, so you will need to build it manually. If you have trouble with that, let us know. Alternatively, you might copy it from any certificate you know which has the desired ExtendedKeyUsage. Apologies for this inconvenience, I do think it would be beneficial to have some helper function for writing such an important extension as ExtendedKeyUsage which doens't force users to hand-craft ASN.1. Best, Hanno ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Thomas Volgmann via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Friday, April 3, 2020 9:01 AM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] How to generate a certificate request with X.509 OID MBEDTLS_OID_SERVER_AUTH Hello, I have a problem generating the following content in an certificate request : Requested Extensions: X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Basic Constraints: CA:FALSE The only thing I could produce was : Requested Extensions: X509v3 Key Usage: Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication: Can anybody help me with the function : mbedtls_x509write_csr_set_extension Mit freundlichen Grüßen Thomas Volgmann --------------------------------------- DSA-Volgmann Redcarstr. 20 53842 Troisdorf Tel: 02241 23416 11 Fax: 02241 23416 61 email : thomas.volgmann(a)dsa-volgmann.de<mailto:thomas.volgmann@dsa-volgmann.de> web: www.dsa-volgmann.de<http://www.dsa-volgmann.de/> --------------------------------------- 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.

5 years

1
0
0 0

Re: [mbed-tls] Allowing unsupported extensions in X.509 certificates

by Hanno Becker

Hi Lev, I believe that this kind of functionality could be implemented on top of the existing verify-with-callback API `mbedtls_x509_crt_verify_with_cb()`. More precisely, you can enable `MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION` to ignore unknown extensions initially, and then chekc them yourself in the verification callback by manually traversing `mbedtls_x509_crt::v3_ext`. If you detect an extension you cannot make sense of and which is marked critical, you can modify the verification flags. Would that work for you, in principle? Note, though, that this would work at the level of verification, not parsing, which might or might not be acceptable. In this regard you might also be interested in knowing about a significant rewrite of CRT parsing on the `baremetal` branch. The main difference is that the X.509 CRT structure has been stripped down to no longer make use of dynamically allocated memory but instead only provide pointers to the various fields in the certificate. In the case of dynamic-length fields such as the Subject or Issuer names, but also the extension list, inspection shall be done through a newline introduced ASN.1 parsing function int mbedtls_asn1_traverse_sequence_of( unsigned char **p, const unsigned char *end, uint8_t tag_must_mask, uint8_t tag_must_val, uint8_t tag_may_mask, uint8_t tag_may_val, int (*cb)( void *ctx, int tag, unsigned char* start, size_t len ), void *ctx ); https://github.com/ARMmbed/mbedtls/blob/baremetal/include/mbedtls/asn1.h#L3… This function traverses an ASN.1 sequence and triggers a callback for each item found. This functionality could be used to perform the extension traversal in the verification callback or directly after parsing. Which extensions are you interested in, particularly, by the way? If it is a standardized extension, feel free to add support for it under a new compile-time feature flag and file a PR to add it. Cheers, Hanno ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Lev Stipakov via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Friday, April 3, 2020 8:32 AM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: Re: [mbed-tls] Allowing unsupported extensions in X.509 certificates Hi, I am not too much into mbedTLS design and not sure if this would make sense, but what about if we introduce an API to let client decide, what to do with unknown extensions? Let's provide a way for a client to specify a callback typedef int (*mbedtls_x509_crt_unsupported_extension_cb_t)( const mbedtls_asn1_buf *oid ); which could be an argument to a new method int mbedtls_x509_crt_parse_with_ext_cb( mbedtls_x509_crt *chain, const unsigned char *buf, size_t buflen, mbedtls_x509_crt_unsupported_extension_cb_t f_ext_cb ); which is called when parser encounters unsupported extension: /* * Detect supported extensions */ ret = mbedtls_oid_get_x509_ext_type( &extn_oid, &ext_type ); if( ret != 0 ) { /* No parser found, skip extension */ *p = end_ext_octet; if( is_critical ) { /* Data is marked as critical: ask client what to do */ if( f_ext_cb != NULL ) { ret = f_ext_cb( &extn_oid ); } /* Client is OK with unsupported critical extension, continue */ if( ret == 0 ) continue; return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + MBEDTLS_ERR_ASN1_UNEXPECTED_TAG ); } continue; } This would allow us to deprecate MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION - those clients which want to allow all extensions could pass a callback which always returns 0. What do you think? -- -Lev -- 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.

5 years

1
0
0 0

Re: [mbed-tls] Allowing unsupported extensions in X.509 certificates

by Lev Stipakov

Hi, I am not too much into mbedTLS design and not sure if this would make sense, but what about if we introduce an API to let client decide, what to do with unknown extensions? Let's provide a way for a client to specify a callback typedef int (*mbedtls_x509_crt_unsupported_extension_cb_t)( const mbedtls_asn1_buf *oid ); which could be an argument to a new method int mbedtls_x509_crt_parse_with_ext_cb( mbedtls_x509_crt *chain, const unsigned char *buf, size_t buflen, mbedtls_x509_crt_unsupported_extension_cb_t f_ext_cb ); which is called when parser encounters unsupported extension: /* * Detect supported extensions */ ret = mbedtls_oid_get_x509_ext_type( &extn_oid, &ext_type ); if( ret != 0 ) { /* No parser found, skip extension */ *p = end_ext_octet; if( is_critical ) { /* Data is marked as critical: ask client what to do */ if( f_ext_cb != NULL ) { ret = f_ext_cb( &extn_oid ); } /* Client is OK with unsupported critical extension, continue */ if( ret == 0 ) continue; return( MBEDTLS_ERR_X509_INVALID_EXTENSIONS + MBEDTLS_ERR_ASN1_UNEXPECTED_TAG ); } continue; } This would allow us to deprecate MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION - those clients which want to allow all extensions could pass a callback which always returns 0. What do you think? -- -Lev

5 years

1
0
0 0

How to generate a certificate request with X.509 OID MBEDTLS_OID_SERVER_AUTH

by Thomas Volgmann

Hello, I have a problem generating the following content in an certificate request : Requested Extensions: X509v3 Extended Key Usage: TLS Web Server Authentication X509v3 Basic Constraints: CA:FALSE The only thing I could produce was : Requested Extensions: X509v3 Key Usage: Digital Signature X509v3 Extended Key Usage: TLS Web Server Authentication: Can anybody help me with the function : mbedtls_x509write_csr_set_extension Mit freundlichen Grüßen Thomas Volgmann --------------------------------------- DSA-Volgmann Redcarstr. 20 53842 Troisdorf Tel: 02241 23416 11 Fax: 02241 23416 61 email : thomas.volgmann(a)dsa-volgmann.de<mailto:thomas.volgmann@dsa-volgmann.de> web: www.dsa-volgmann.de<http://www.dsa-volgmann.de/> ---------------------------------------

5 years

1
0
0 0

Re: [mbed-tls] TLS context serialization: can it be done?

by Hanno Becker

Hi Dmitrii! The reason why we focused on DTLS 1.2 + AEAD for the context serialization was because that's what we needed to support quickly at the time, and not because we saw some fundamental technical obstacles in implementing context serialization for TLS 1.2. I did the same as you, commenting out DTLS checks, and ran into the same problem during `mbedtls_cipher_auth_decrypt()`. The problem turns out to be the following: In TLS, the context contains an incoming record counter which, while in DTLS, the record counter is explicit and hence need not be maintained. In particular, when using the current serialization+deserialization functions with TLS 1.2, the incoming record counter will be corrupted. The core of the fix is simple: You need to duplicate https://github.com/ARMmbed/mbedtls/blob/development/library/ssl_tls.c#L6228… and https://github.com/ARMmbed/mbedtls/blob/development/library/ssl_tls.c#L6496… -- which save/load the _outgoing_ counter -- for the incoming counter `ssl->in_ctr`. I just tried this and things worked afterwards. Could you try and see if it works for you, too? If so, please feel free to adapt the serialization functions and file a PR to add support for serialization in TLS, and mark me as a reviewer. Note: There will likely be other things that need fixing, too, so please be careful in using the above patch as-is unless for experimentation. Cheers, Hanno ________________________________ From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Kuvaiskii, Dmitrii via mbed-tls <mbed-tls(a)lists.trustedfirmware.org> Sent: Tuesday, March 31, 2020 8:58 PM To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org> Subject: [mbed-tls] TLS context serialization: can it be done? Dear all, I have the following question. mbedTLS v2.21.0 has support for TLS context serialization in the form of two functions: `mbedtls_ssl_context_save()` and `mbedtls_ssl_context_load()`. I'm trying to use these functions in another project (Graphene, an Intel SGX framework). Slightly oversimplifying, I want to establish a secure communication channel between two different Linux processes. I'd like to persist one of them and then re-spawn it again with the communication channel intact (so that there is no need for a new TLS handshake). However, I notice that currently these functions support only DTLS 1.2, see e.g.: https://github.com/ARMmbed/mbedtls/blob/aaabe86ac1f47193f4fc499846a0b3abeae… But I want to use a normal TLS channel, in particular with a ciphersuite `MBEDTLS_TLS_PSK_WITH_AES_128_GCM_SHA256`. I commented out the checks on DTLS in these functions just to see what will happen. As expected, both functions serialized and then deserialized the context, but when doing a `write(ssl_ctx)` in one (not-persisted) process and a `read(loaded_ssl_ctx)` in another (re-spawned) process, I get an error in `mbedtls_cipher_auth_decrypt()`. Clearly, my deserialized context didn't restore some vital information on the TLS session, and this led to failure in decryption. Thus, I have two questions: 1. Is there any version of this code that also works on TLS? 2. What are the additional internal objects that must be serialized for TLS (if it makes things easier, in my particular case with AES-GCM and a pre-shared key)? I looked at the code and tried to dump more fields in `mbedtls_ssl_transform`, but it didn't help much. If you'd provide me with some pointers, I could tinker more with mbedTLS code and hopefully make it work. Thanks in advance for any pointers! -- Dmitrii -- 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.

5 years

2
2
0 0

Re: [mbed-tls] question: SIGPIPE handling

by Gilles Peskine

On 01/04/2020 11:29, Anibal Portero via mbed-tls wrote: > SIGPIPE is handled with a signal( SIGPIPE, SIG_IGN ) in mbedtls_net_connect. While the examples in programs/ssl/ssl_client1.c or programs/ssl/ssl_client2.c are calling mbedtls_net_connect, programs/ssl/mini_client.c is not, and therefore not changing the default behavior of SIGPIPE. > Our client is based on mini_client.c. What would the best way to handle SIGPIPE? Would it be worth it to add signal( SIGPIPE, SIG_IGN ) to the mini_client.c example for future reference? maybe even make net_prepare() visible from outside so a mini client like application can use it? That's a good question. I wonder why mbedtls_net_connect() calls signal(). It's been the case ever since net.c was introduced in XySSL 0.5. But that's a global setting and I don't think a library function that's supposed to act on a specific socket should modify a global setting. Should mbedtls_net_send() call send(MSG_NOSIGNAL) instead of write()? But what about older systems without MSG_NOSIGNAL? Is there a portable way to disable SIGPIPE for a specific socket? -- Gilles Peskine Mbed TLS developer 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.

5 years

1
0
0 0

Allowing unsupported extensions in X.509 certificates

by Gilles Peskine

Hello, This is a discussion about the design of a new feature in X.509 parsing, and a possible deprecation of MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION. Normally, when mbedtls_x509_crt_parse() (specifically x509_get_crt_ext()) encounters an extension that it doesn't support (unknown OID), it rejects the certificate if the extension is marked as critical and ignores it otherwise. This is usually the right thing. The application can inspect all extensions, including ignored ones, in crt->v3_ext. However there are use cases where it's useful to pass extensions through to the application and let the application decide, even for critical extensions. There's a compilation flag MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION (default off) which causes critical extensions to be ignored. However the application must then parse the extension list again to check for all critical extensions, including ones that it doesn't support. https://github.com/ARMmbed/mbedtls/pull/1425 proposes to give the application better control. At least the application should be able to specify at runtime which extensions it allows. And perhaps the parser should provide pointers to the extensions that it finds. The design needs to reconcile several aspects, in particular: • With default compile-time and run-time options, unsupported critical extensions must be rejected, both for security and for backward compatibility. • With MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION and default run-time options, all critical extensions must be accepted, for backward compatibility. • It's nicer if the library includes knowledge about extension OIDs. However this needs to be balanced against the needs of embedded systems where code size is important and the current size of oid.o is already a problem. • Compile-time options increase the testing burden, so it's better not to add one. And non-default compile-time options aren't useful for platforms that use a shared library built by a distribution. With these considerations, how should a runtime mechanism to select pass-through critical extensions be implemented? Can we do it without a new compile-time option and without increasing the code size? Should the new mechanism be present in the default build, only with MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION or only with a new compile-time option? MBEDTLS_X509_ALLOW_UNSUPPORTED_CRITICAL_EXTENSION has been around since before my time. I don't know who might be using it. Should we deprecate it if there's a more flexible runtime mechanism that doesn't involve turning it on? -- Gilles Peskine Mbed TLS developer

5 years

1
0
0 0

Re: [mbed-tls] Static Memory allocation Buffer Size for DTLS #3146

by Manuel Pegourie-Gonnard

Hi, > I am not sure how much memory to assign? I don't think there's a simple answer to that. I think the best you can do is measure how much memory is consumed in your workflow, and add a margin. When doing measurements, you should keep in mind that DTLS handshakes may consume more memory when happening over an unreliable transport, as it then needs to cache out-of-order messages, so you might want to use something like our programs/test/udp_proxy to simulate an unreliable link for you measurements. Also, the size of the messages exchanged (and potentially cached) depends on the size of the certificate chain, so you'll want to do you measurements with a configuration as close as possible to the final one. > > Current use: 33 blocks / 2508 bytes, max: 99 blocks / 5392 bytes (total 8560 bytes), alloc / free: 8803 / 8771 > What is blocks here and how many bytes per block? > My understanding is that - out of 99 blocks, 33 blocks are used. Is it right? In this context, a block just means an area of memory that is or was allocated. So for example if you do `malloc(128); malloc(1024);` you'll have two blocks used, the first being 128 bytes (plus overhead) and the second 1024 bytes (plus overhead). There is no fixed number or size of blocks in the allocator, so here the "max" means the peak of memory consumption - at that time, 5392 bytes had been allocated, over 99 blocks. You'll notice our allocator has a pretty large overhead: when adding administrative data used by the allocator, the peak memory consumption was actually 8560 bytes, out of which only 5392 were actually available to the application. > Does the memory fragmentation and de-fragmentation is handled inside mbedTLS itself? No, the provided allocator is very basic and doesn't protect against memory fragmentation. > And also after every handshake, does it release the used memory buffer for the connection? Once the handshake is complete, all the RAM that was allocated just for the handshake is freed, and the only buffers that are kept are those that are still necessary for the rest of the connection. Hope that helps! Best regards, Manuel.

5 years, 1 month

1
0
0 0

question: SIGPIPE handling

by Anibal Portero

Hi, SIGPIPE is handled with a signal( SIGPIPE, SIG_IGN ) in mbedtls_net_connect. While the examples in programs/ssl/ssl_client1.c or programs/ssl/ssl_client2.c are calling mbedtls_net_connect, programs/ssl/mini_client.c is not, and therefore not changing the default behavior of SIGPIPE. Our client is based on mini_client.c. What would the best way to handle SIGPIPE? Would it be worth it to add signal( SIGPIPE, SIG_IGN ) to the mini_client.c example for future reference? maybe even make net_prepare() visible from outside so a mini client like application can use it? Thanks!

5 years, 1 month

1
0
0 0

Static Memory allocation Buffer Size for DTLS #3146

by ROSHINI DEVI

I am directing the issue - https://github.com/ARMmbed/mbedtls/issues/3146 The content of the issue is - Hello, Currently I am using mbed tls 2.16.3 and I am using it on STM32L4xx platform. Before I was using dynamic memory allocation (heap), now planning to shift to static memory allocation. I am using x509 ecc based certificate. I am using DTLS handshake. I am also using "mbedtls_memory_buffer_alloc_status" to print the status of static buffer. The queries are - 1. I am not sure how much memory to assign? 2. I am not able to understand the message - *Current use: 33 blocks / 2508 bytes, max: 99 blocks / 5392 bytes (total 8560 bytes), alloc / free: 8803 / 8771* What is blocks here and how many bytes per block? My understanding is that - out of 99 blocks, 33 blocks are used. Is it right? 1. Does the memory fragmentation and de-fragmentation is handled inside mbedTLS itself? And also after every handshake, does it release the used memory buffer for the connection? I need the values correct to make sure not to get the memory allocation failure Please help me in these queries.

5 years, 1 month

1
0
0 0

TLS context serialization: can it be done?

by Kuvaiskii, Dmitrii

Dear all, I have the following question. mbedTLS v2.21.0 has support for TLS context serialization in the form of two functions: `mbedtls_ssl_context_save()` and `mbedtls_ssl_context_load()`. I'm trying to use these functions in another project (Graphene, an Intel SGX framework). Slightly oversimplifying, I want to establish a secure communication channel between two different Linux processes. I'd like to persist one of them and then re-spawn it again with the communication channel intact (so that there is no need for a new TLS handshake). However, I notice that currently these functions support only DTLS 1.2, see e.g.: https://github.com/ARMmbed/mbedtls/blob/aaabe86ac1f47193f4fc499846a0b3abeae… But I want to use a normal TLS channel, in particular with a ciphersuite `MBEDTLS_TLS_PSK_WITH_AES_128_GCM_SHA256`. I commented out the checks on DTLS in these functions just to see what will happen. As expected, both functions serialized and then deserialized the context, but when doing a `write(ssl_ctx)` in one (not-persisted) process and a `read(loaded_ssl_ctx)` in another (re-spawned) process, I get an error in `mbedtls_cipher_auth_decrypt()`. Clearly, my deserialized context didn't restore some vital information on the TLS session, and this led to failure in decryption. Thus, I have two questions: 1. Is there any version of this code that also works on TLS? 2. What are the additional internal objects that must be serialized for TLS (if it makes things easier, in my particular case with AES-GCM and a pre-shared key)? I looked at the code and tried to dump more fields in `mbedtls_ssl_transform`, but it didn't help much. If you'd provide me with some pointers, I could tinker more with mbedTLS code and hopefully make it work. Thanks in advance for any pointers! -- Dmitrii

5 years, 1 month

1
0
0 0

Stability of the development environment for long-time support branches

by Gilles Peskine

Hello, In Mbed TLS long-time support branches (currently 2.7.x and 2.16.x), we make bug fixes, but we preserve backward compatibility as much as possible. This means that as much as possible, we don't change existing behavior unless it's definitely wrong, we don't add new APIs, we don't increase the code size. We also preserve backward compatibility with build and deployment processes for projects that use the library. We don't create new source files, we don't change the name of makefile targets, we don't add new tools requirements or tool version requirements to build the library and its tests, etc. For example: * We added Python as a requirement to build the tests shortly before the 2.16 release, but kept the existing Perl script in the 2.7 LTS. * We've changed config.pl to a Python script in development, but kept it in Perl in LTS branches. * We've dropped support for older Visual Studio version in development, but kept it in LTS branches. How far should this extend to non-core files, such as documentation and higher-level test scripts? For example: * We're considering tweaking the format of the ChangeLog file. Should we preserve the format strictly in LTS branches? * How about renaming ChangeLog to CHANGES or CHANGES.md? * We're considering rewriting some multi-configuration test scripts and maintainer sanity checks such as tests/scripts/depends-*.pl, tests/scripts/all.sh, tests/scripts/check-names.sh, etc., in Python. (Note that we've already done that with new scripts added to all.sh: Python was not a requirement to pass all.sh in 2.7.0, but it is now.) -- Gilles Peskine Mbed TLS developer

5 years, 1 month

1
0
0 0

Welcome to Mbed TLS @ TrustedFirmware.org

by Dan Handley

Welcome to the Mbed TLS list @ TrustedFirmware.org! This mailing list is the primary channel for public discussion, questions and announcements about the Mbed TLS project. Please use this where possible in preference to the GitHub issue tracker or private support channels. The GitHub issue tracker should still be used for raising bugs and enhancement requests (after first checking the issue doesn't already exist). Thanks and regards Dan.

5 years, 1 month

1
0
0 0

Test message - please ignore

by Bill Fletcher

You may safely ignore this message -- [image: Linaro] <http://www.linaro.org/> *Bill Fletcher* | *Field Engineering* T: +44 7833 498336 <+44+7833+498336> bill.fletcher(a)linaro.org | Skype: billfletcher2020

5 years, 1 month

1
0
0 0

Welcome to Mbed TLS @ TrustedFirmware.org

by Dan Handley

Welcome to the Mbed TLS list @ TrustedFirmware.org! This mailing list is the primary channel for public discussion, questions and announcements about the Mbed TLS project. Please use this where possible in preference to the GitHub issue tracker or private support channels. The GitHub issue tracker should still be used for raising bugs and enhancement requests (after first checking the issue doesn't already exist). Thanks and regards Dan.

5 years, 1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

mbed-tls