- mbed-tls - lists.trustedfirmware.org

by Satya Prakash Prasad

Hi, I am working on an issue related to memory leak in MBedTLS. We have integrated MBedTLS code for below 3rd party HostAPD code integration . https://github.com/prplfoundation/hostap [Hostapd] Please refer to the Hostapd peer code implementation as provided in the link below: https://github.com/prplfoundation/hostap/blob/master/eap_example/eap_exampl… https://github.com/prplfoundation/hostap/blob/master/eap_example/eap_exampl… The main function code snippet is provided below: https://github.com/prplfoundation/hostap/blob/master/eap_example/eap_exampl… if (eap_example_peer_init() < 0 || eap_example_server_init() < 0) return -1; do { printf("---[ server ]--------------------------------\n"); res_s = eap_example_server_step(); printf("---[ peer ]----------------------------------\n"); res_p = eap_example_peer_step(); } while (res_s || res_p); Since we are implementing code for peers hence we have removed the server step. Now we need to keep monitoring for new connections / failed connections and act accordingly we have modified the code to something like below - if (eap_example_peer_init() < 0 || eap_example_server_init() < 0) return -1; do { res_p = eap_example_peer_step(); if (eap_ctx.eapNoResp || eap_ctx.eapFail) { eap_client_peer_deinit(); eap_client_peer_init(); } } while (1); We have modified the loop such that it will keep iterating for new connections and in case of failure, re-initialization is required. Is my understanding correct? The issue I am facing is that the client peer deinit method is not releasing all memory allocated during eap_example_peer_step() function ( I understand while processing the EAP TLS server request). The deinit is purely implemented to deallocate memory initially allocated for a new connection using TLS? void eap_client_peer_deinit(void) { eap_peer_sm_deinit(eap_ctx.eap); eap_peer_unregister_methods(); wpabuf_free(eap_ctx.eapReqData); os_free(eap_ctx.eap_config.identity); os_free(eap_ctx.eap_config.password); os_free(eap_ctx.eap_config.cert.ca_cert); os_free(eap_ctx.eap_config.cert.client_cert); os_free(eap_ctx.eap_config.cert.private_key); } where void eap_peer_sm_deinit(struct eap_sm *sm) { if (sm == NULL) return; eap_deinit_prev_method(sm, "deinit"); eap_sm_abort(sm); if (sm->ssl_ctx2) tls_deinit(sm->ssl_ctx2); tls_deinit(sm->ssl_ctx); eap_peer_erp_free_keys(sm); os_free(sm); } Can you please let me know whether we are deallocating memory correctly? Thanks in advance. Regards, Prakash

7 months

1
0
0 0

Handshake is successful if the intermediate CA is revoked.

by singaravelu Balasubramani

I am checking the certificate revocation with below scenario. I have Root CA, Intermediate CA and device certificate is signed by Intermediate CA. I am makeing chain certificate by combining Root CA, Intermediate CA and this chain certificate is my active CA certificate and loaded this and device certificate to the drive. From client, I am creating client certificate which is signed by same intermeidate CA. Making ssl handshake. Handshake is success as expected. Now i am revoking the intermediate CA and creating the crl which is signed by the Root CA. This crl has the serial number of intermediate CA. Now loading the CRL to the drive and setting the crl in "mbedtls_ssl_conf_ca_chain". Now i am establishing the ssl connection with the same client ceritificate and expecting the ssl handshake failure due to intermediate CA revoked. But i get handshake is success. Is my understanding right about intermediate CA revocation? I did little background debug, and my obervation is During handshake , it goes to static int x509_crt_verify_chain function in mbedtls. Its trying to find the parent using x509_crt_find_parent for the client certificate and get intermediate CA. During this time, parent_is_trusted is set as true. after this x509_crt_verifycrl is called with client certificate (child), intermediate CA (parent) and crl(has the intermediate CA serial number-issued by Root CA). During x509_crt_verifycrl check, it check for CRL issuer with ca subject and return 0, as its not matching. now in x509_crt_verify_chain , /* prepare for next iteration */ ., they are marking child_is_trusted = parent_is_trusted and child = parent, parent = NULL; and while loop continues, in loop, x509_crt_verify_chain checks for child_is_trusted is true and return as 0. But its not checking that intermediate CA is revoked or not. /* Stop here for trusted roots (but not for trusted EE certs) */ if( child_is_trusted ) return( 0 );

7 months

2
2
0 0

Question about mbedtls_x509_parse_subject_alt_name

by Roman Janota

Hello, I would like to parse certificate's SAN fields in my application. In the documentation of the struct mbdetls_x509_crt for its member subject_alt_names the following is stated: "Optional list of raw entries of Subject Alternative Names extension. These can be later parsed by mbedtls_x509_parse_subject_alt_name.". I was using the latest development branch and tried to call the function, however, I found out I can not, because it is defined in the x509_internal.h private header. I later found out that the definition was moved from the public to the private header in the commit 25b282e <https://github.com/Mbed-TLS/mbedtls/commit/25b282ebfe5cb84e73d6194e83dc8d6c…> (partly thanks to the issue #459 <https://github.com/Mbed-TLS/mbedtls/issues/459>). So I switched to the 3.5.2 release and everything worked fine. Why was this change made? Will it be kept so that I'd have to implement my own parsing? Or was it a mistake? Thank you for clarifying, Roman.

7 months, 1 week

1
0
0 0

SHA-256 mismatch for mbedtls-3.5.2.tar.gz

by Wojtek Porczyk

Hello, list, Release notes for Mbed TLS 3.5.2 [0] have this: The SHA256 hashes for the archives are: 35890edf1a2c7a7e29eac3118d43302c3e1173e0df0ebaf5db56126dabe5bb05 mbedtls-3.5.2.tar.gz 55c1525e7d5de18b84a1d1e5540950b4a3bac70e02889cf309919b2877cba63b mbedtls-3.5.2.zip However, attempting to download mbedtls-3.5.2.tar.gz yields a file with hash: eedecc468b3f8d052ef05a9d42bf63f04c8a1c50d1c5a94c251c681365a2c723 What's going on with those hashes? [0]: https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.5.2 https://web.archive.org/web/20240126105153/https://github.com/Mbed-TLS/mbed… -- pozdrawiam / best regards Wojtek Porczyk Gramine / Invisible Things Lab I do not fear computers, I fear lack of them. -- Isaac Asimov

7 months, 2 weeks

3
7
0 0

Question about fix of "Timing side channel in private key RSA operations"

by Yuxiang Cao

Hi folks, This is a question about understanding changes in recent new release. I want to understand how new release e.g. 2.28.7 fix the vulnerable described in https://mbed-tls.readthedocs.io/en/latest/security-advisories/mbedtls-secur…. Want to check that if following commits in new release, for example 2.28.7, are the actual commits for fixing the vulnerable above: 42175031ca48e2fba62b97fc802e5df33d5221ff 4fe396f1e1aa84346e23b89435a251624c205035 aa6760d7b5d9a218eaf072f4155974f58b00986b 601bffc4cec7c78cfc6b64048379172578fce13c In short, they are first 4 commits in I found https://github.com/Mbed-TLS/mbedtls/compare/v2.28.6...v2.28.7 Thank you for any help you can provide! Best, Yuxiang

7 months, 3 weeks

2
2
0 0

Public And Private Keys

by Satya Prakash Prasad

Hi, I need some clarification on Public and Private keys that a server maintains its own side. All documents say that the client will use the server's public key to encrypt the data while the server will make use of its private keys to decrypt. Is it not that the data can be decrypted using the public key itself? How and what is encryption logic implemented in such a case? Please do provide some logical explanation for the same - how does this encryption / decryption work? Regards, Prakash

7 months, 3 weeks

1
0
0 0

Mbed TLS 3.5.2 and 2.28.7

by Dave Rodgman

Hi Mbed TLS users, We have released Mbed TLS versions 3.5.2 and 2.28.7. These releases contain security fixes for: a timing side channel in private key RSA operations; and a buffer overflow in mbedtls_x509_set_extension. Full details are available in the release notes. https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-2.28.7 https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.5.2 We recommend all users to consider whether they are impacted, and to upgrade appropriately. Many thanks. Dave

7 months, 4 weeks

1
0
0 0

ECDH - establish shared secret key with X509 certificate + private key

by Tilen MAJERLE

Dear community, My target is to establish a shared secret key between the PC application (master) and (various, different, but always limited to 1 at a time) peripheral devices. *Each device has*: - Device specific ECC 256-bit private key, in PEM format, well parsed with mbedtls_pk_parse_key function when required. - Device specific certificate that belongs to the private key. Certificate is signed by the *TrustCA*. Parsing works well with mbedtls_x509_crt_parse - TrustCA’s certificate, used to validate the master device during communication, also used to check firmware signature in a secure boot part of the application *PC application has*: - Master application certificate, signed by *TrustCA* - Private key of the PC application that belongs to master application certificate, in PEM format - *TrustCA*’s certificate, used to validate device certificate during communication Aim is to establish AES shared secret, by doing: - Master sends authentication requests, random challenge, device performs hash + signs with private key. Returns certificate + signature of the challenge. - Master uses *TrustCA*'s certificate to check device's certificate and then checks the signature of the hash(challenge) - Master sends its certificate to the slave, now both hold X509 certificates. At this point, device could also request authentication of the PC application - A computation with its respective private key is needed on both sides, and we have common secret. What is the correct way in mbedTLS, to get a public key from *X509*, that can be used in the ECDH module? The way the ECDH module inside mbedTLS seems to be designed, there is no straight-forward way to export X5090’s public key, get its parameters and use them in ECDH module. Instead, ECDH expects that random keypair will be generated every-time we want key exchange. Doing this, we risk *man in the middle* attack, since the other party doesn’t know where the key is actually coming from. For the moment, the solution I see (which is not THAT elegant, or is it?), and to avoid man in the middle attack:: - Devices still exchange certificates, but only for authentication reason + certificate verification - Every message that is sent between devices (for instance public keys exchange), must also be hashed & signed, so that another party can be sure message is coming from the device which shared the certificate just before (and certificate is signed by TrustCA) - We need one exchange more to get shared secret. Is this the *proposed* solution in this case? Is there a more elegant solution with the mbedTLS library for this problem? Thanks -- Tilen Majerle, mag.inž.el. Tušev Dol 11 8340 Črnomelj Slovenia www: http://majerle.eu e-mail: tilen(a)majerle.eu Mobile: +386 40 167 724 <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free.www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#m_-5461752537485879190_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

8 months

1
0
0 0

Dropping support for Visual Studio 2015

by Gilles Peskine

Hello, We are considering dropping support for Visual Studio 2013 and Visual Studio 2015 from Mbed TLS 3.6 onwards. This would make Mbed TLS 3.6 require Visual Studio 2017 or newer. (Mbed TLS 2.28 LTS is not affected.) Per the Visual Studio product lifecycle <https://learn.microsoft.com/en-us/visualstudio/productinfo/vs-servicing#old…>, VS 2013 and 2015 are currently on extended support, but their support will end during the lifetime of Mbed TLS 3.6 LTS. Our reasons are: * We prefer not to support products that are not supported upstream, such as VS 2013 and 2015 will be during the lifetime of 3.6 LTS. * Older versions of Visual Studio tend to require workarounds due to their incomplete support for C99, and we would like to reduce those. We may drop support for older versions of MinGW as well for this reason. * The development branch of Mbed TLS is currently triggering an internal compiler error in VS 2015 <https://github.com/Mbed-TLS/mbedtls/issues/8735>. If you want to keep support for VS 2013 and 2015 in Mbed TLS 3.6, please let us know as soon as possible and tell us why it's important. Assistance with the internal compiler error would be appreciated. Best regards, -- Gilles Peskine Mbed TLS developer

8 months

1
0
0 0

.MBed TLS - Transport / Network Level Implementation

by Satya Prakash Prasad

Hi, Please let me know if MBed TLS is designed for Security level at Transport / Network Level Implementation of OSI model - at network socket connection level. Please let us know if MBed TLS routines can be used at DataLink Layer specifically for 802.1x protocols. Referring to the example as provided in tutorial - https://mbed-tls.readthedocs.io/en/latest/kb/how-to/mbedtls-tutorial/ What would be setup / config accordingly for non socket dependent implementation. Thanks in advance. Regards, Prakash

8 months

1
0
0 0

2024

2023

2022

2021

2020

mbed-tls