Hi Team,
I am working on exploring DTLS handshake using the mbedtls-3.6.4 version on
our embedded platform. I enabled the hello verify request feature and got
stuck at hello verify request state on server side if I don't reset the ssl
context and don't set the client transport ID. I want to know if there is
any way to complete a handshake by bypassing the reset of ssl context and
setting the client transport ID.
Also, our environment only supports C89 constructs. I could not see
inttypes.h in the mbedtls-3.6.4, is there any specific reason to remove
this file? I am getting compilation errors without inttypes.h and stdint.h.
Is there any macro to be enabled to support the c89 compilation in mbedtls
stack?
Looking forward to your response.
Thanks and regards,
Ankita Hatmode
--
-------------------------------------------------------------------------------------------------------------------------
**Disclaimer:** This email message including any attachments is
confidential, and may be privileged and proprietary to Agiliad. If you are
not the intended recipient, please notify us immediately by replying to
this message and destroy all copies of this message including any
attachments. You are NOT authorized to read, print, retain, copy,
disseminate, distribute, or use this message or any part thereof. Thank
you.
------------------------------------------------------------------------------------------------------------------------
Dear MbedTLS maintainers,
we are already using MBedTLS, however, we recently enabled TLS 1.3 and
found that our certificates doesn't work anymore, because they are
brainpoolP256r1 (https://datatracker.ietf.org/doc/html/rfc8734). So the
question would be, if I missed any configuration to enable the usage of
brainpool curves (which are working for TLS 1.2) or if there are any
plans, that these are getting supported by MBedTLS 3.6.x?
Best regards,
Maren Konrad
Hi
We migrated from mbedtls 2.28 to mbedtls 3.6.2
https://github.com/Mbed-TLS/mbedtls/tree/107ea89daaefb9867ea9121002fbbdf926…
and
we see TLS handshake fails when we use TLS 1.2 in mbedtls 3.6.2 instead of
1.3.
We get below error
20E094B0FFFF0000:error:0A000126:SSL routines:ssl3_read_n:unexpected eof
while reading:/usr/src/debug/openssl/3.1.0-r0/ssl/record/rec_layer_s3.c:303:
# openssl s_client -connect 192.168.142.1:7001 -no_tls1_3 fails
After seeing the trace we have enabled ciphers but still we see the issue.
please advise, thanks.
Thanks
Kavitha
Hi Mbed TLS users,
We have released Mbed TLS versions 3.6.4.
These releases of Mbed TLS address several security issues, provide bug fixes, and bring other minor changes. Full details are available in the release notes (https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.4).
We recommend all users to consider whether they are impacted, and to upgrade appropriately.
Hi,
Prior to the first TLS handshake our application is required to perform input validation of the provided credentials (from file or smart card) for this peer.
One of those checks is to verify that private and public key match.
We used to use mbedtls_pk_sign() with a custom mbedtls_pk_context for that.
But in version 3.X mbedtls_pk_info_t was made private so mbedtls_pk_setup() with a custom mbedtls_pk_info_t whose sign_func would call into our smart card wrapper is no longer possible.
Is there still a way to provide custom callback functions for signing in 3.6.4 somehow? Or any other workaround for early check of a key pair?
Looking at 4.0.0-beta, also pk.h is no longer public.
Will it still be possible to perform early validation of this peer's credentials prior to a first TLS handshake? How?
While I am at it, it would be good to implement something that is future-proof.
What else I have looked at:
* mbedtls_pk_setup_opaque() might be the way to go but I do not find an example of how to link a key id to a custom signature function.
* mbedtls_pk_setup_rsa_alt() would be useful if our application was always using RSA.
* Both functions are no longer public in 4.0
Related:
Early validation of a CRL (whether it was signed by the expected CA) used to be possible with mbedtls_pk_verify_ext().
But to properly set the input parameters requires access to private members of mbedtls_x509_crl in 3.6.4 (maybe an acceptable move?) but in 4.0.0 mbedtls_pk_verify_ext() is no longer public.
How perform explicit/"manual" CRL validation especially given the possibly skipped CRL validation in mbedtls_x509_crt_verify() as per the comment below?
"It is your responsibility to provide up-to-date CRLs for all trusted CAs. If no CRL is provided for the CA that was used t sign the certificate, CRL verification is skipped silently..."
Any future-proof ideas for this?
Best regards,
/Almut
We are pleased to introduce Velositi Consultancy Group, a Finnish-owned brokerage and consultancy firm headquartered in Ontario, Canada.
As the exclusive representative of leading financial institutions across Oman, Saudi Arabia, and Dubai, we offer customized financing solutions globally. Through our partners, we provide loan facilities at a competitive 3% annual interest, featuring a 2-year grace period and no physical collateral—a unique offer tailored for today’s business environment.
This opportunity is extended especially to recognized business leaders like yourself. Your recent listing by your country’s Chamber of Commerce as “Reliable to do business with” during the Saudi Business Summit highlights the potential for meaningful collaboration.
Beyond direct financing, we also welcome broker partnerships for referring businesses in need of funding.
We would be pleased to discuss how we can support your growth and financial objectives.
Warm regards,
Liam Gill
Chairman, Business Development
Velositi Consultancy Group
300 John Street, Suite 506, Thornhill, ON L3T 6M8, Canada
LIAM GILL
300 John Street, Suite 506 , ON , Thornhill , L3T 6M8
Unsubscribe ( https://u45460243.ct.sendgrid.net/wf/unsubscribe?upn=u001.AzuRT3u7SiTsBx5mQ… ) - Unsubscribe Preferences ( https://u45460243.ct.sendgrid.net/wf/unsubscribe?upn=u001.AzuRT3u7SiTsBx5mQ… )
I am happy to announce the joint-release of Mbed TLS 4.0.0-beta & TF-PSA-Crypto 1.0.0-beta
PSA-Crypto now lives in its own repository while TLS and X.509 remain in Mbed TLS.
This beta release breaks compatibility with earlier versions of Mbed TLS.
Please do not use it in production.
It’s intended for the community to verify codebase integrations against the split and API changes, and for early adopters to experiment and provide feedback.
For full details, please see the release pages:
Mbed TLS 4.0.0-beta: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.0.0-beta
TF-PSA-Crypto 1.0.0-beta: https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.0.0-…
I am happy to announce the joint-release of Mbed TLS 4.0.0-beta & TF-PSA-Crypto 1.0.0-beta
PSA-Crypto now lives in its own repository while TLS and X.509 remain in Mbed TLS.
This beta release breaks compatibility with earlier versions of Mbed TLS.
Please do not use it in production.
It’s intended for the community to verify codebase integrations against the split and API changes, and for early adopters to experiment and provide feedback.
For full details, please see the release pages:
Mbed TLS 4.0.0-beta: https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-4.0.0-beta
TF-PSA-Crypto 1.0.0-beta: https://github.com/Mbed-TLS/TF-PSA-Crypto/releases/tag/tf-psa-crypto-1.0.0-…
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.
--
Mbed-tls-announce mailing list -- mbed-tls-announce(a)lists.trustedfirmware.org
To unsubscribe send an email to mbed-tls-announce-leave(a)lists.trustedfirmware.org