- mbed-tls - lists.trustedfirmware.org

TLS handshake with AWS IoT MQTT broker seems to succeed and then is terminated by the broker

by Roger Sala

I am developing an AWS IoT MQTT client on STM32H723 using FreeRTOS 10.3.1, LwIP 2.1.2 and MbedTLS. My first attempt used MbedTLS 2.16.2 and it mostly works except that sometimes, seemingly related to the timing of the network I'm using, it fails when my client fails to send out anything after the Client Key Exchange message and then the server responds with a Close Notify as follows: "Time","Source","Destination","Protocol","Length","Info" "0.000000","10.24.108.94","54.157.158.237","TLSv1.2","418","Client Hello" "0.016460","54.157.158.237","10.24.108.94","TLSv1.2","150","Server Hello" "0.002777","54.157.158.237","10.24.108.94","TLSv1.2","685","Certificate" "0.000000","54.157.158.237","10.24.108.94","TLSv1.2","438","Server Key Exchange, Certificate Request, Server Hello Done" "0.976521","10.24.108.94","54.157.158.237","TLSv1.2","1006","Certificate, Client Key Exchange" "0.014853","54.157.158.237","10.24.108.94","TLSv1.2","61","Alert (Level: Warning, Description: Close Notify)" When it works it looks like this: "Time","Source","Destination","Protocol","Length","Info" "0.000000000","10.0.0.11","54.84.254.130","TLSv1.2","418","Client Hello" "0.017495225","54.84.254.130","10.0.0.11","TLSv1.2","150","Server Hello" "0.001743255","54.84.254.130","10.0.0.11","TLSv1.2","685","Certificate" "0.000022282","54.84.254.130","10.0.0.11","TLSv1.2","392","Server Key Exchange" "0.000004428","54.84.254.130","10.0.0.11","TLSv1.2","100","Certificate Request, Server Hello Done" "2.606030441","10.0.0.11","54.84.254.130","TLSv1.2","1326","Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message" "0.027421478","54.84.254.130","10.0.0.11","TLSv1.2","105","Change Cipher Spec, Encrypted Handshake Message" "0.000971482","10.0.0.11","54.84.254.130","TLSv1.2","193","Application Data" "0.075384354","54.84.254.130","10.0.0.11","TLSv1.2","87","Application Data" The last two "Application Data" messages are the MQTT connect and connect ACK, So before I filed a bug report, I upgraded to MbedTLS 2.28.4. The good news is that this client always (seems) to successfully negotiate the TLS handshake, but after receiving the first encrypted "Application Data" (connect), the broker immediately sends and "Encrypted Alert", which I'm taking to be a Close Notify because a TCP FIN follows shortly thereafter. The Wireshark capture of the 2.28.4 handshake looks almost exactly like the successful 2.16.2 handshake: "Time","Source","Destination","Protocol","Length","Info" "0.000000000","10.0.0.11","44.195.98.16","TLSv1.2","336","Client Hello" "0.018450117","44.195.98.16","10.0.0.11","TLSv1.2","150","Server Hello" "0.000524146","44.195.98.16","10.0.0.11","TLSv1.2","685","Certificate" "0.000003168","44.195.98.16","10.0.0.11","TLSv1.2","392","Server Key Exchange" "0.000002995","44.195.98.16","10.0.0.11","TLSv1.2","100","Certificate Request, Server Hello Done" "2.517148776","10.0.0.11","44.195.98.16","TLSv1.2","1329","Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message" "0.016572792","44.195.98.16","10.0.0.11","TLSv1.2","60","Change Cipher Spec" "0.000007326","44.195.98.16","10.0.0.11","TLSv1.2","99","Encrypted Handshake Message" "0.001500778","10.0.0.11","44.195.98.16","TLSv1.2","193","Application Data" "0.031014646","44.195.98.16","10.0.0.11","TLSv1.2","85","Encrypted Alert" ... except for the "Encrypted Alert" from the broker that leads to the closing of the session. I'm hoping someone has an explanation of the behavior I'm seeing and can suggest a path forward for me. Another data point is the fact that the client with MbedTLS 2.28.4 can successfully authentic and negotiate a TLS handshake with a mosquitto broker I'm running locally using self signed certificates. ====================================================================== The information contained in this e-mail, including all of its attachments, is confidential and proprietary information of IPG Photonics and its affiliates and intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender by telephone or e-mail, and destroy this communication and all copies. Thank you. ======================================================================= This Email has been scanned for all viruses by IPG Photonics Email Scanning Services.

1 year, 9 months

1
0
0 0

Reminder: MBed TLS Tech Forum - Asia/Europe

by Don Harbin

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

1 year, 9 months

2
2
0 0

New TrustedFirmware Discord Server

by Don Harbin

Hi All, Note you may have received another instance of this note but when I attempted to send to all TF ML's simultaneously it seemed to fail, so sending to each one at a time. Sorry about that. :/ We've created a Discord Server for real time chats/sharing. This solution comes at no cost to the project, is set up with channels for each project, includes a #general channel, and supports direct 1-1 chats between members, all with the goal of improving collaboration between trustedfirmware.org developers. We encourage all to join! :) Instructions for joining can be found on the TF.org FAQ page <https://www.trustedfirmware.org/faq/>. See you all there and please don't hesitate to reach out if you have any questions! Don Harbin TrustedFirmware Community Manager don.harbin(a)linaro.org

1 year, 9 months

1
0
0 0

New TrustedFirmware Discord Server

by don.harbin＠linaro.org

The content of this message was lost. It was probably cross-posted to multiple lists and previously handled on another list.

1 year, 9 months

1
0
0 0

Does mbedtls support x509 certificates signed wih ED448 algorithm?

by Bahadır Maktav

Hi, I am trying to use a certificate with its public key algorithm is NIST P-384 and its signature algorithm is ED448. I am working on ESP board with IDF framework which supports mbedtls. But when I am trying to use that certificate, I got error message about 'MBEDTLS_ERR_X509_UNKOWN_SIG_ALG'. So, I thought that maybe mbedtls does not support certificates which signed with ED448.

1 year, 10 months

2
1
0 0

Does mbedtls support x509 certificates signed wih ED448 algorithm?

by Bahadır Maktav

Hi, I am trying to use a certificate with its public key algorithm is NIST P-384 and its signature algorithm is ED448. I am working on ESP board with IDF framework which supports mbedtls. But when I am trying to use that certificate, I got error message about 'MBEDTLS_ERR_X509_UNKOWN_SIG_ALG'. So, I thought that maybe mbedtls does not support certificates which signed with ED448.

1 year, 10 months

1
0
0 0

Example of AEAD decrypt?

by Christian Huitema

The example of AEAD encryption in "aead_demo" is very useful. Is there a similar example for decryption? -- Christian Huitema

1 year, 10 months

2
1
0 0

Does mbedTLS TLS1.3 only support PSK?

by Thompson, Jeff

I've got mbedTLS 3.1.4 and want to use TLS 1.3. My handshake fails very early because I don't have any Pre-Shared Keys. Does mbedTLS TLS1.3 only support PSKs, or can I still use generated session keys as does TLS 1.2? If so, how? Jeff Thompson | Senior Electrical Engineer - Firmware +1 704 752 6513 x1394 www.invue.com [cid:image001.gif@01D9D729.620C6230]

1 year, 10 months

2
2
0 0

Silly python problem when building on MacOS

by Christian Huitema

Hello, I am trying to build MbedTLS on a Mac, as part of a project to support MbedTLS in the "picoquic" implementation of QUIC. I have a small problem, probably something of my making. I have cloned the repo on an "mbedtls" directory, created a "build" subdirectory, and from there run"cmake ..", which worked fine, and then tried to run "make", which fails in "generating psa_crypto_driver_wrapper.c" when trying the python script "generate_driver_wrappers.py" because it cannot find the python module "jsonschema". I tried to solve that by installing that module using "pip", and test programs running python3 do find the "jsonschema". Calling print(jsonschema.__file__) shows the module is installed in my user directory: /users/christianhuitema/Library/python3.9/lib/python/... Is there a simple way to fix that? -- Christian Huitema

1 year, 10 months

2
4
0 0

Certificate Revocation

by ahmed bouzid

Hello, I'm currently engaged in a project where I'm utilizing mbedtls for the management of certificates. Within this project, I'm aiming to integrate a revocation feature using Certificate Revocation Lists (CRLs). However, my search for resources on how to effectively implement a comprehensive certificate revocation process using mbedtls has unfortunately yielded no productive outcomes. I am concerned about how to first create a crl file and sign it using my self-signed CA, how to revocate a certificate if we need to revocate it, and how to update the CRL, then when parsing the cert how to detect that this certificate has been revocated. ( I am using LPCXpresso55S16 as a client and raspberry pi as a server and I am doing all with coding). Thank you in advance for your support. Best regards, Ahmed.

1 year, 10 months

2
1
0 0

2025

2024

2023

2022

2021

2020

mbed-tls