I am using MbedTLS client code based on this:
https://github.com/machinezone/IXWebSocket/blob/master/ixwebsocket/IXSocket…
I am connecting to a server via it's URL. However, I would like to connect directly using an IP address returned from running the traceroute command on the URL.
So I replaced the URL with the IP address. However, MBedTLS fails on the handshake:
https://github.com/machinezone/IXWebSocket/blob/master/ixwebsocket/IXSocket…
I get the error:
"error in handshake : X509 - Certificate verification failed, e.g. CRL, CA or signature check failed"
If I revert back to URL, it works. The IP address does exist.
How can I connect using the IP address, instead of the URL?
Hi All,
A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech
forum is next Monday at 10:00am PM UK time. Invite details can be found on
the online calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
ReplyReply to allForward
Compose:
Community activity: OpenCV, Sensors, AI
[image: Minimise][image: Pop-out][image: Close]
Compose:
Reminder: MBed TLS Tech Forum - Asia/Europe
[image: Minimise][image: Pop-out][image: Close]
Recipients
Hi,
I have an inhouse developed secure authentication program that uses certificate for authentication. I have used mbedtls library for the x.509 certificate verification purpose. In our custom PKI we have only three level of certificates, Root-CA -> Intermediate-CA -> Device-Cert.
The embedded device has very limited memory, so instead of sending whole certificate chain, the devices communicates intermediate_CA and device cert (in der format base64 encoded) in separate packet. Root-CA will be available on node as trusted-ca. Intermediate is verified against Root; then device cert is verified against intermediate.
The problem is, the poc developed on linux platform is working fine - but on embedded platform I encounter either 0x3b00(parsing failed) or 0x2700(with flag 8). Also the error code are inconsistent.
I verified the integrity of packet with certificate using crc16. So no chance of certificate getting corrupted. Also verified the certificate's base64 format integrity using crc16.
All certificates are sha256WithRSAEncryption; RSA Public-Key: (4096 bit)
Attached config.h on target platform for reference - could you help me if anything wrong with configuration.
While trying to trace, the flag was set from x509_crt.c from below code.
/* No parent? We're done here */
if( parent == NULL )
{
printf("NO_PARENT\r\n");
*flags |= MBEDTLS_X509_BADCERT_NOT_TRUSTED;
return( 0 );
}
Any clue would be helpful.
Thanks,
Gopi Krishnan
Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is next Monday at 4:30 PM UK time. Invite details can be found on the
online calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi Team,
Referring to MBed release page -
https://github.com/Mbed-TLS/mbedtls/releases?page=1 I see that there has
been constant release periodically from Jul 27, 2018 mbedtls-2.1.14
till Nov 8, 2023 v3.5.1.
In the same context I understand that with each release there have been
fixes and new features / enhancement implementation. There was a project
that I was working in year 2020 were we tried to integrate MBed TLS in EAP
https://github.com/prplfoundation/hostap. It was a practice exercise that
our team did that time. I have not much idea as to which MBed TLS version
was opted and integrated then.
Now that so many new releases are made after 2020 - are older versions can
be taken as stable?
Is it that we should take the latest version and try again from scratch?
Thanks in advance.
Regards,
Prakash
Hi All,
A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech
forum is next Monday at 10:00am PM UK time. Invite details can be found on
the online calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
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
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
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.7https://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
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>
