Hi,
I am trying to build lief which is dependent on mbedtls as a static library.
I am using conan recipe to build using cmake.
The build of the library succeeded, however later while trying to build my
own application and link with lief I get the following error:
LIEF.lib(x509.obj) : error LNK2001: unresolved external symbol
mbedtls_snprintf
What do I do wrong?
Or should I configure something while building the mbedtls library ?
Thanks,
Gal.
Dear Mbed TLS maintainers,
I have surveyed Mbed TLS and know that it has features which can improve
AES block cipher performance by hardware instructions instead of SW
implementation
e.q., AESCE of ARMV8 and AESNI of INTEL.
AS far as I know about RISC-V Cryptography extension(Zkne and Zknd),
it also supports relevant AES instructions which can accelerate aes
key schedule, encryption and decryption process.
(https://tools.cloudbear.ru/docs/riscv-crypto-spec-scalar-1.0.0-rc6-20211012…)
I want to ask for your opinions and agreement.
Is there any willingness to accept this RISC-V accelerated feature
idea and contribution to Mbed TLS ?
If you agree with it, I would like to prepare a pull request for you to review.
Sincerely,
Rick
Dear Mbed TLS users,
We have released Mbed TLS version 3.6.2. This release provides a security fix for an out-of-bounds write vulnerability in the pkwrite module.
Full details are available in the release notes:
https://github.com/Mbed-TLS/mbedtls/releases/tag/mbedtls-3.6.2
We recommend all users to consider whether they are impacted, and to upgrade appropriately.
Many thanks,
David Horstmann
Mbed TLS developer
Hi,
I'm currently working on adding mbedTLS 3.x support for Privoxy [0].
Everything seems to be working but I ifdef'ed out the following
code in [1] that worked with mbedTLS 2.28.8:
/*
* Check if key and issuer certificate match
*/
if (!mbedtls_pk_can_do(&issuer_cert.pk, MBEDTLS_PK_RSA) ||
mbedtls_mpi_cmp_mpi(&mbedtls_pk_rsa(issuer_cert.pk)->N,
&mbedtls_pk_rsa(*issuer_key)->N) != 0 ||
mbedtls_mpi_cmp_mpi(&mbedtls_pk_rsa(issuer_cert.pk)->E,
&mbedtls_pk_rsa(*issuer_key)->E) != 0)
{
log_error(LOG_LEVEL_ERROR,
"Issuer key doesn't match issuer certificate");
ret = -1;
goto exit;
}
As N and E are private now it no longer compiles.
Is there a way to implement the check with mbedTLS 3.x?
My impression is that the sanity check is overly cautious
and we don't have equivalent code for OpenSSL and wolfSSL
but I'm curious.
Thanks,
Fabian
[0] <https://www.privoxy.org/>
[1] <https://www.privoxy.org/gitweb/?p=privoxy.git;a=blob;f=ssl.c;h=e8007cd9adad…>
Hello,
I'm running into an issue with using Mbed-TLS on an embedded device of ours and I'm curious if anyone would be able to point me in the right direction. If this is the wrong channel for general use questions, let me know and I'll search elsewhere. As a forewarning, I'm still getting my bearings around the nuts and bolts of Mbed-TLS and network security; apologies if I misstate something or jumble things up.
Our device uses Mbed-TLS 3.0.0; ideally I'd like to upgrade this to a newer version, but this version was included in a SDK package for our device and I'd like to get some basic functionality proven out first before trying to reintegrate a newer version into the rest of provided code. The current goal is to get our device to serve a web page over HTTPS with TLS.
What we currently see is that the initial hello client and server messages are exchanged without issue, but the connection is rejected after the server requests a certificate from the client. In some browsers, this opens a prompt where you can select a given certificate on the machine; in others, it skips this prompt and sends a response back with an empty certificate. In both instances, the server will return an error and deny the connection.
This seems like some sort of user configuration error, given your average web page served over HTTPS on the internet avoids making this request. The literature I've been able to find so far also seems to suggest this request is entirely optional. Is there some option I'm overlooking that makes the server skip asking the client for its certificate and lets connection continue on?
Michael Reutman
Senior Embedded Software Engineer
NovaTech Automation
261 Brodhead Rd.
Bethlehem, PA 18017
novatechautomation.com<http://www.novatechautomation.com/> | NovaTechLinkedIn<https://www.linkedin.com/company/565017>
NovaTech Automation is Net Zero committed. #KeepItCool<https://www.keepitcool.earth/>
Receipt of this email implies compliance with our terms and conditions<https://www.novatechautomation.com/email-terms-conditions>.
Hi,
I'm trying to parse this DER encoded certificate in hex format:
3082018230820128a003020102020900f3b305f55622cfdf300a06082a8648ce3d04030230003020170d3735303130313030303030305a180f34303936303130313030303030305a30003059301306072a8648ce3d020106082a8648ce3d0301070342000458f7e9581748ff9bdd933b655cc0e5552a1248f840658cc221dec2186b5a2fe4641b86ab7590a3422cdbb1000cf97662f27e5910d7569f22feed8829c8b52e0fa38188308185308182060a2b0601040183a25a01010101ff0471306f042508021221026b053094d1112bce799dc8026040ae6d4eb574157929f1598172061f753d9b1b04463044022040712707e97794c478d93989aaa28ae1f71c03af524a8a4bd2d98424948a782302207b61b7f074b696a25fb9e0059141a811cccc4cc28042d9301b9b2a4015e87470300a06082a8648ce3d04030203480030450220143ae4d86fdc8675d2480bb6912eca5e39165df7f572d836aa2f2d6acfab13f8022100831d1979a98f0c4a6fb5069ca374de92f1a1205c962a6d90ad3d7554cb7d9df4
This certificate is part of a simple test for this specification
https://github.com/libp2p/specs/blob/master/tls/tls.md
I'm using this https://github.com/status-im/nim-mbedtls Nim language
library wrapper for mbedtls. I don't know the mbedtls version exactly,
but the lib is based on this commit
https://github.com/Mbed-TLS/mbedtls/tree/09d23786f6fdcb4dfa88aad30c8767bd27….
In my code I use:
proc parseUnverified*(derInput: seq[byte]) =
var crt: mbedtls_x509_crt
mbedtls_x509_crt_init(addr crt)
var ret = mbedtls_x509_crt_parse_der(addr crt, unsafeAddr
derInput[0], derInput.len.uint)
if ret != 0:
raise newException(Exception, "Failed to parse certificate, error
code: " & $ret)
which is a straightforward version of the C code, but ti fails with:
Failed to parse certificate, error code: -9186 [Exception]
It seems the problem is because the certificate doesn't have the
Distinguished Name set. Does it make sense? If this is really the
cause of the problem, is there any workaround?
Regards.
Hi,
We were using old MBed TLS version 2.19.1 and existing trusted CA
certificates were working fine in that release. Recently we upgraded
to 3.6.0 and see that now certificate parsing is returning -ox262e
value from function mbedtls_x509_get_sig_alg cause of which handshake
is not even initiated.
Can you please let us know what can cause such an issue and remedy the same?
Regards,
Prakash
Hi Mbed TLS,
I am looking for some suggestions about make some (or all) Mbed TLS APIs non-secure callable APIs on armv8m.
The background is that I am going to have a secure firmware that provides encryption services by building part (or whole) of Mbed TLS into that firmware and make those original mbedtls_x APIs non-secure callable, so the existing non-secure firmware could link those non-secure callable APIs and use them.
Some of my thoughts:
(1) The easiest way to do it I can think of is just add the attribute "cmse_nonsecure_call" to those APIs' declaration (or use a macro to wrap the attribute for conditional build to not impact others don't want it), but I do not think this modification could be accepted by upstream 🙂.
(2) So my another thought is duplicate all header files and put them under another folder, assuming it is my-include folder, then I can do whatever I want to my-include folder, but there is also a problem I can think of: a merge/compare burden between include and my-include folder after I have updated Mbed TLS.
I really appreciate other suggestions!
Thanks,
William
Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is next Monday at 4:30pm UK time. Invite details can be found on the online
calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Janos know. :)
Don
