- mbed-tls - lists.trustedfirmware.org

mbedtls 2.28 - resumption in an ongoing session (abbreviated renegotiation)

by Tommaso Mancini

Hello, I am trying to test a device’s conformance to IEC62351-3 which defines some rules about TLS implementations, in particular im wondering if it’s possible to: Use mbedtls on a TLS server to accept a session resumption when a client sends a ClientHello message with a session ID in an ongoing TLS session. Also RFC 5246 says this about resumption for tls v1.2: The ClientHello message includes a variable-length session identifier. If not empty, the value identifies a session between the same client and server whose security parameters the client wishes to reuse. The session identifier MAY be from an earlier connection, this connection, or from another currently active connection. so it should be possible to resume in an ongoing session but: I already have a working implementation of a TLS 1.2 server using mbedtls 2.28, but if a client sends a clienthello with a session ID in an ongoing session, the server always responds with a renegotiation by default. Taking a look at the library code i tried to change the function: static void ssl_handle_id_based_session_resumption(mbedtls_ssl_context *ssl) found in the file ssl_srv.c in mbedtls 2.28, and removed a check which skipped resumption if a client hello was received during a session, this does not work properly however because the server closes the connection after sending the finished message due to a MBEDTLS_SSL_ALERT_MSG_DECRYPT_ERROR. Im wondering if there is anyway to allow resumption in this manner using mbedtls or if im doing something wrong? If you require further information please let me know and i will try to add as much as i can! [1741361442716] <mailto:tommaso.mancini@sel-electric.it> Tommaso Mancini SEL S.p.A. R&D Software and Test Engineer Via Amendola 9,11,13,15,17 51035 Lamporecchio (PT) Tel. +39 0573 80051 Fax +39 0573 803110 website: www.sel-electric.com<http://www.sel-electric.com/> e-mail: tommaso.mancini(a)sel-electric.it<mailto:tommaso.mancini@sel-electric.it> <mailto:tommaso.mancini@sel-electric.it>Questo è un messaggio di posta elettronica proveniente da SEL s.p.a. Le informazioni contenut in questa comunicazione sono altamente riservate e possono essere utilizzate solo dalla persona o dall’ente cui sono destinate. La diffusione, distribuzione e/o copiatura del documento trasmesso da parte di qualsiasi soggetto diverso dal destinatario è proibita. Se avete ricevuto questo messaggio per errore, Vi preghiamo di contattarci immediatamente. Grazie. This communication is intended only for use by the addressee. It may contain confidential or privileged information. Transmission cannot be guaranteed to be secure or error-free. If you receive this communication unintentionally, please inform us immediately. Thank you. Per favore, pensa all’ambiente prima di stampare. Please, consider the environment before you print.

1 week, 2 days

1
0
0 0

Some problems regarding mbed TLS

by Milorad Podoaba

Hello, Our devices are connecting to AWS IoT Core. Recently we had few customers with poor connection complaining that the device didn't reconnect. We are using ARM Keil MDK 8.1.0 + mbed TLS 3.6.4. On Wireshark logs we have identified 2 errors: 1. close notify from server after client hello 2. bad certificate or unknown CA from client after server hello The device was stuck on one of these errors and only a reboot would fix it. I think these 2 errors are not related. On detail analysis for the first error, we saw that the cipher suites list was missing and that was the reason for close notify from server. Looking at the TLS code saw that the list is being created only one time after reboot. So in ssl_ciphersuites.c just commented out supported_init = 1 and now seems to be good. I do not know the reason why the list was lost during runtime. For the second error, we were able to reproduce the problem quite consistently. Some logs at IoT client code showed that somehow the TLS lost the ability to parse properly the server certificates. I believe that this was some memory allocation problem, so I've configured the mbed TLS to get allocation from a separate buffer and that seems to fix the problem. This buffer has to be quite large, 56k size. Any smaller size would return memory allocation failure. Any reason why it has to be so big? Just want to know if someone had before these issues and if I can lower the buffer. Let me know if you need extra details about the problems. Thank you and regards, Milo -- MiloradPodoaba Firmware System Engineer Arrowhead Alarm Products Ltd. (09) 414 0085 <tel:%2809%29%20414%200085%20%20%20> milo(a)aap.co.nz <mailto:milo@aap.co.nz> www.aap.co.nz <//www.aap.co.nz> 1A Emirali Road, Silverdale, Auckland, New Zealand facebook <https://www.facebook.com/ArrowheadAlarmProductsLtd/?hc_ref=ARTrnwMZmLZimX6K…> linkedin <https://www.linkedin.com/company/arrowhead-alarm-products-ltd-/> instagram <https://instagram.com/aapltd?igshid=1356ehzmruf5r>

1 week, 2 days

3
3
0 0

Fwd: Some problems regarding mbed TLS

by Ben Taylor

Also anything you can share around the size and quantity of certificates you are parsing would be useful. 56K does seem very high, though if at the time you are parsing large numbers of large certificates it could get up that far. Regards Ben ---------- Forwarded message --------- From: Ben Taylor <ben.taylor(a)linaro.org> Date: Tue, 27 Jan 2026 at 11:33 Subject: Re: [mbed-tls] Some problems regarding mbed TLS To: Milorad Podoaba <milo(a)aap.co.nz> Hi Milo, For the second issue the memory allocation problem if you are able to share your mbedtls configuration, that would be useful as customising this could impact how much is allocated. Beyond this anything further you can share about how you are using the library when you encounter high usage would be useful. Ideally a code snippet which reproduces the error, though if not any further information will help us reproduce the error and attempt to assist you. For the first issue again if you can share your config and any code snippets you have that can reproduce the issue that would be helpful. Many thanks Ben On Mon, 26 Jan 2026 at 20:54, Milorad Podoaba <milo(a)aap.co.nz> wrote: > Hi Ben, > > Not sure how much code you want me to share. You need to be more specific. > There might be a memory problem in our application, it just hard to tell > and the mbed TLS seems not able to recover. > > At this stage, I only want to reduce the size of the buffer for the > alternative memory alloc. > Do you know a way to do it? > > Thank you and regards, > Milo > > > Milorad Podoaba > > Firmware System Engineer > > Arrowhead Alarm Products Ltd. > > > > (09) 414 0085 <%2809%29%20414%200085%20%20%20> > milo(a)aap.co.nz > www.aap.co.nz <//www.aap.co.nz> > 1A Emirali Road, Silverdale, Auckland, New Zealand > > > > [image: facebook] > <https://www.facebook.com/ArrowheadAlarmProductsLtd/?hc_ref=ARTrnwMZmLZimX6K…> > > [image: linkedin] > <https://www.linkedin.com/company/arrowhead-alarm-products-ltd-/> > > [image: instagram] <https://instagram.com/aapltd?igshid=1356ehzmruf5r> > > > On 27/01/2026 12:19 am, Ben Taylor wrote: > > Hi Milo, > Thanks for reporting this issue. Is there any chance you could > share some example code that can reproduce the error, so we can investigate > it further? > > Many thanks > > Ben > > On Mon, 26 Jan 2026 at 10:28, Milorad Podoaba via mbed-tls < > mbed-tls(a)lists.trustedfirmware.org> wrote: > >> Hello, >> >> Our devices are connecting to AWS IoT Core. >> Recently we had few customers with poor connection complaining that the >> device didn't reconnect. >> >> We are using ARM Keil MDK 8.1.0 + mbed TLS 3.6.4. >> >> On Wireshark logs we have identified 2 errors: >> >> 1. close notify from server after client hello >> 2. bad certificate or unknown CA from client after server hello >> >> The device was stuck on one of these errors and only a reboot would fix >> it. >> I think these 2 errors are not related. >> >> On detail analysis for the first error, we saw that the cipher suites >> list was missing and that was the reason for close notify from server. >> Looking at the TLS code saw that the list is being created only one time >> after reboot. >> So in ssl_ciphersuites.c just commented out supported_init = 1 and now >> seems to be good. >> I do not know the reason why the list was lost during runtime. >> >> For the second error, we were able to reproduce the problem quite >> consistently. >> Some logs at IoT client code showed that somehow the TLS lost the ability >> to parse properly the server certificates. >> I believe that this was some memory allocation problem, so I've >> configured the mbed TLS to get allocation from a separate buffer and that >> seems to fix the problem. >> This buffer has to be quite large, 56k size. Any smaller size would >> return memory allocation failure. >> Any reason why it has to be so big? >> >> Just want to know if someone had before these issues and if I can lower >> the buffer. >> Let me know if you need extra details about the problems. >> >> Thank you and regards, >> Milo >> >> >> -- >> Milorad Podoaba >> >> Firmware System Engineer >> >> Arrowhead Alarm Products Ltd. >> >> >> >> (09) 414 0085 <%2809%29%20414%200085%20%20%20> >> milo(a)aap.co.nz >> www.aap.co.nz <//www.aap.co.nz> >> 1A Emirali Road, Silverdale, Auckland, New Zealand >> >> >> >> [image: facebook] >> <https://www.facebook.com/ArrowheadAlarmProductsLtd/?hc_ref=ARTrnwMZmLZimX6K…> >> [image: linkedin] >> <https://www.linkedin.com/company/arrowhead-alarm-products-ltd-/> >> [image: instagram] <https://instagram.com/aapltd?igshid=1356ehzmruf5r> >> -- >> mbed-tls mailing list -- mbed-tls(a)lists.trustedfirmware.org >> To unsubscribe send an email to mbed-tls-leave(a)lists.trustedfirmware.org >> > >

1 week, 3 days

2
1
0 0

PSA Key derivation driver entry points

by Ruchika Gupta

Hi All, The PSA driver interface guide describes the driver entry points for key derivation. However the implementation seems to be missing from the psa crypto core layer. Can you help update if this is something which is being worked on ? I see a lot of tickets open related for key derivation interface dating back in 2022. Are these still relevant ? Regards, Ruchika

3 weeks, 5 days

2
1
0 0

Canceled event: MBed-TLS Technical Forum - Asia @ Mon 29 Dec 2025 10am - 10:50am (GMT) (mbed-tls@lists.trustedfirmware.org)

by Shaun Longhorn

This event has been canceled. MBed-TLS Technical Forum - Asia Monday 29 Dec 2025 ⋅ 10am – 10:50am United Kingdom Time Trusted Firmware is inviting you to a scheduled Zoom meeting.Topic: MBed-TLS Technical Forum - AsiaTime: Jun 16, 2025 10:00 AM London Every 4 weeks on Mon, 39 occurrence(s)Please download and import the following iCalendar (.ics) files to your calendar system.Weekly: https://linaro-org.zoom.us/meeting/tJMqcuGuqDotGtIbACm498ytl0ZhydWKdu1b/ics… Zoom Meetinghttps://linaro-org.zoom.us/j/97758661706?pwd=baMjUvnWbY20z3ignQca7QVahhozkI.1Meeting ID: 977 5866 1706Passcode: 577208---One tap mobile+16892781000,,97758661706# US+17193594580,,97758661706# US---Dial by your location• +1 689 278 1000 US• +1 719 359 4580 US• +1 253 205 0468 US• +1 253 215 8782 US (Tacoma)• +1 301 715 8592 US (Washington DC)• +1 305 224 1968 US• +1 309 205 3325 US• +1 312 626 6799 US (Chicago)• +1 346 248 7799 US (Houston)• +1 360 209 5623 US• +1 386 347 5053 US• +1 507 473 4847 US• +1 564 217 2000 US• +1 646 558 8656 US (New York)• +1 646 931 3860 US• +1 669 444 9171 US• +1 669 900 9128 US (San Jose)• 833 548 0282 US Toll-free• 833 928 4608 US Toll-free• 833 928 4609 US Toll-free• 833 928 4610 US Toll-free• 877 853 5247 US Toll-free• 888 788 0099 US Toll-free• 833 548 0276 US Toll-freeMeeting ID: 977 5866 1706Find your local number: https://linaro-org.zoom.us/u/acdtApJNbc Guests mbed-tls(a)lists.trustedfirmware.org psa-crypto(a)lists.trustedfirmware.org ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 month, 3 weeks

1
0
0 0

Question about using hardware-backed parameters in ALT crypto implementations

by Massimiliano Cialdi

Hi, I’m working with Mbed TLS 2.28.x on a microcontroller that provides a built-in crypto engine. The existing *_ALT support works fine for performance, and higher-level modules correctly route their block operations through the accelerated backend. On this platform the crypto hardware can also use internal key material stored in dedicated slots. These values are not accessible as byte arrays and cannot be passed to the usual setkey_*() API. Question Is there a recommended way to configure an ALT implementation so that it can select an internal key slot instead of receiving a buffer? Or, more generally, how should an ALT backend represent a key that is not exposed to software? Any guidance on the intended design would be appreciated. Thanks! Massimiliano Cialdi FIRMWARE ENGINEERING PROFESSIONAL LEADER Powersoft S.p.A. Via E. Conti, 5 - Scandicci (Fi) 50018 - Italy OFFICE: +39 055 7350230 [cid:2_3b23bc2c-3db3-4330-b6f5-3fb62b89422a.png]<https://www.facebook.com/powersoft/>[cid:3_7da2eb67-7c7f-41e6-9598-128bdd52ec04.png]<https://www.instagram.com/powersoft.official/>[cid:4_a5d469e7-3228-4fb1-948d-4c3e879ea0da.png]<https://www.youtube.com/@powersoftaudio>[cid:5_e4390674-51fd-4219-9389-28ae9a12796d.png]<https://www.linkedin.com/company/powersoft>[cid:6_083a55f9-076c-4d52-9f93-69225b28cb32.png]<https://open.spotify.com/show/6lwXROYcCyrVnJi6J9fA42>[cid:7_7fd8585e-63fd-441a-95f3-6c0b23d059e1.png]<https://x.com/Powersoft_Japan>[cid:8_6308aaa9-b97d-405b-a86c-0300a381d13f.png]<https://space.bilibili.com/3546387314641333>[cid:9_9af1e42f-0019-42c4-8046-d6246e65ed9e.png]<https://teams.microsoft.com/l/chat/0/0?users=massimiliano.cialdi@powersoft.…> [cid:pwsrgbn_12214209-f50f-45fa-be18-2a4cf1a5818a.png]<https://www.powersoft.com/en>

2 months, 2 weeks

2
1
0 0

Re: How can I read plain-text private key into rsa_context?

by Shannek Pierce

05 DC AD 24 F4 E4 B1 C4 39 15 62 45 02 DC 7B 4A C6 57 8F FC 40 5B 5E 6F 55 FB E1 F6 58 62 CB 57 05 Sent from my iPhone

2 months, 3 weeks

1
0
0 0

AI Policy - Guidance on AI-assisted contributions

by Shaun Longhorn

All, Please be aware that today we have published our AI policy with Guidance on AI-assisted contributions. See the full details here: https://www.trustedfirmware.org/aipolicy/ Should you have any questions feel free to raise them. Thanks, Shaun Community Manager

2 months, 3 weeks

1
0
0 0

Re: [Hafnium] Re: Gerrit scheduled maintenance: 8th November 8-12 UTC

by Saheer Babu

Hi Jerome Could you try again please? Thanks, Saheer From: Jerome Forissier <jerome.forissier(a)linaro.org> Date: Monday, 10 November 2025 at 10:19 To: Saheer Babu <Saheer.Babu(a)arm.com>, tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>, tf-rmm(a)lists.trustedfirmware.org <tf-rmm(a)lists.trustedfirmware.org>, hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>, mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>, olivier.deprez--- via Tf-openci <tf-openci(a)lists.trustedfirmware.org> Subject: Re: [Hafnium] Re: Gerrit scheduled maintenance: 8th November 8-12 UTC Hi Saheer, On 11/9/25 00:19, Saheer Babu via Hafnium wrote: > Hi > > Just wanted to let you all know that maintenance was done in the morning and site is back to normal. I'm getting a 403 from here: $ curl --show-headers https://review.trustedfirmware.org/ HTTP/2 403 server: awselb/2.0 date: Mon, 10 Nov 2025 10:14:55 GMT content-type: text/html content-length: 118 <html> <head><title>403 Forbidden</title></head> <body> <center><h1>403 Forbidden</h1></center> </body> </html> Same for git.trustedfirmware.org which makes the OP-TEE CI fail: https://github.com/OP-TEE/optee_os/actions/runs/19226835413/job/54955917815… Regards, -- Jerome > > Thanks, > Saheer > > From: Saheer Babu <Saheer.Babu(a)arm.com> > Date: Thursday, 30 October 2025 at 16:13 > To: tf-m(a)lists.trustedfirmware.org <tf-m(a)lists.trustedfirmware.org>, tf-rmm(a)lists.trustedfirmware.org <tf-rmm(a)lists.trustedfirmware.org>, hafnium(a)lists.trustedfirmware.org <hafnium(a)lists.trustedfirmware.org>, mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>, olivier.deprez--- via Tf-openci <tf-openci(a)lists.trustedfirmware.org> > Subject: Gerrit scheduled maintenance: 8th November 8-12 UTC > Hi All, > > We will be performing maintenance activity on review.trustedfirmware.org and service will be unavailable on 8th November between 8 AM-11 AM UTC. > > Best regards, > > Saheer >

2 months, 4 weeks

1
0
0 0

FW: CI infrastructure scheduled maintenance: 12th Sep 2025

by Joanna Farley

FYI From: Saheer Babu via Tf-openci <tf-openci(a)lists.trustedfirmware.org> Date: Wednesday, 10 September 2025 at 15:17 To: tf-openci(a)lists.trustedfirmware.org <tf-openci(a)lists.trustedfirmware.org> Subject: [Tf-openci] CI infrastructure scheduled maintenance: 12th Sep 2025 Hi all, We will be performing upgrade of the clusters hosting review.trustedfirmware.org and ci.trustedfirmware.org on Friday, 12th Sep 2025 at 16:00 GMT+1. During this maintenance window, both services will be unavailable for approximately 4 hours. A follow-up email will be sent once the services are fully restored. Best regards, Saheer 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. -- Tf-openci mailing list -- tf-openci(a)lists.trustedfirmware.org To unsubscribe send an email to tf-openci-leave(a)lists.trustedfirmware.org

3 months

2
3
0 0

2026

2025

2024

2023

2022

2021

2020

mbed-tls