Hi Manuel,

At least, the issue is now tracked. Thanks for your additional feedback, this is mainly what we also thought. It would have been too easy if the patch was working with few lines of changes.

My team and I are not mbed TLS experts, not sure if we can provide help here. But if you need some testers, just let me know.

Regards,
Jérémy
From: Manuel Pegourie-Gonnard <Manuel.Pegourie-Gonnard@arm.com>
Sent: Wednesday, April 14, 2021 12:16
To: mbed-tls@lists.trustedfirmware.org <mbed-tls@lists.trustedfirmware.org>; Jérémy Audiger <jeremy.audiger@ioterop.com>
Subject: Re: TLS serialization
 
Hi Jérémy,

Thanks for your question! Indeed, the context (de)serialization feature only support DTLS so far. We've added an enhancement request to our backlog to extend it to TLS: https://github.com/ARMmbed/mbedtls/issues/4340

However, it may take some time before we get to it, as we're currently focused on preparing Mbed TLS 3.0. Also, this enhancement may very well turn out to be more complex that it might look initially: TLS is a reliable stream protocol (as opposed to DTLS which is an unreliable datagram protocol) and there will probably be some precautions to take and corner case to handle in order to make sure the full stream is preserved.

If you or anyone else wants to open a PR for that, that would obviously help - though again, I'm afraid we'll have little review bandwidth until the end of June. (More generally, it's always a good idea to coordinate on the list before raising a large or complex PR.)

Regards,
Manuel.
From: mbed-tls <mbed-tls-bounces@lists.trustedfirmware.org> on behalf of Jérémy Audiger via mbed-tls <mbed-tls@lists.trustedfirmware.org>
Sent: 12 April 2021 18:39
To: mbed-tls@lists.trustedfirmware.org <mbed-tls@lists.trustedfirmware.org>
Subject: [mbed-tls] TLS serialization
 
Hi everyone,

I'm currently trying to add the ability to serialize / deserialize a TLS security session using these APIs:
  • mbedtls_ssl_context_load()
  • mbedtls_ssl_context_save()
I'm on TLS Server-side (so not talking about TLS Client here). After digging through the mailing list, I discovered this previous topic: https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/000012.html and this Github repository: https://github.com/dimakuv/mbedtls-psk-example 
The scenario is the same here: using PSK with ciphersuite MBEDTLS_TLS_PSK_WITH_AES_128_CCM_8

Once the handshake is done, I'm able to serialize the TLS session with the patch attached to this email. After that I'm able to decrypt one incoming packet and encrypt one ongoing packet. So, almost everything is fine. But, when the TLS Server is receiving another message from the TLS Client (message sent in two fragments), the Server is able to decrypt the first fragment but not the second one, getting this error:

ssl_msg.c:5475: 0x7f9aa803d288: => read
ssl_msg.c:4029: 0x7f9aa803d288: => read record
ssl_msg.c:2012: 0x7f9aa803d288: => fetch input
ssl_msg.c:2167: 0x7f9aa803d288: in_left: 0, nb_want: 5
ssl_msg.c:2192: 0x7f9aa803d288: in_left: 0, nb_want: 5
ssl_msg.c:2195: 0x7f9aa803d288: ssl->f_recv(_timeout)() returned 5 (-0xfffffffb)
ssl_msg.c:2215: 0x7f9aa803d288: <= fetch input
ssl_msg.c:3763: 0x7f9aa803d288: dumping 'input record header' (5 bytes)
ssl_msg.c:3763: 0x7f9aa803d288: 0000:  17 03 03 00 41                                   ....A
ssl_msg.c:3765: 0x7f9aa803d288: input record: msgtype = 23, version = [3:3], msglen = 65
ssl_msg.c:2012: 0x7f9aa803d288: => fetch input
ssl_msg.c:2167: 0x7f9aa803d288: in_left: 5, nb_want: 70
ssl_msg.c:2192: 0x7f9aa803d288: in_left: 5, nb_want: 70
ssl_msg.c:2195: 0x7f9aa803d288: ssl->f_recv(_timeout)() returned 65 (-0xffffffbf)
ssl_msg.c:2215: 0x7f9aa803d288: <= fetch input
ssl_msg.c:3874: 0x7f9aa803d288: dumping 'input record from network' (70 bytes)
ssl_msg.c:3874: 0x7f9aa803d288: 0000:  17 03 03 00 41 00 00 00 00 00 00 00 03 27 9d 1a  ....A........'..
ssl_msg.c:3874: 0x7f9aa803d288: 0010:  50 14 ff e1 14 8c b0 f5 de 06 1c f0 43 5c a0 91  P...........C\..
ssl_msg.c:3874: 0x7f9aa803d288: 0020:  46 23 3e 42 86 ed 3a 48 38 3d e8 b4 05 09 50 ac  F#>B..:H8=....P.
ssl_msg.c:3874: 0x7f9aa803d288: 0030:  94 6b 9c fb c6 22 7b 46 62 e0 af 08 ab 60 50 3c  .k..."{Fb....`P<
ssl_msg.c:3874: 0x7f9aa803d288: 0040:  6d c6 c8 7c cb 2c                                m..|.,
ssl_msg.c:1301: 0x7f9aa803d288: => decrypt buf
ssl_msg.c:1414: 0x7f9aa803d288: dumping 'additional data used for AEAD' (13 bytes)
ssl_msg.c:1414: 0x7f9aa803d288: 0000:  00 00 00 00 00 00 00 02 17 03 03 00 31           ............1
ssl_msg.c:1423: 0x7f9aa803d288: dumping 'IV used' (12 bytes)
ssl_msg.c:1423: 0x7f9aa803d288: 0000:  db 70 01 4b 00 00 00 00 00 00 00 03              .p.K........
ssl_msg.c:1424: 0x7f9aa803d288: dumping 'TAG used' (8 bytes)
ssl_msg.c:1424: 0x7f9aa803d288: 0000:  50 3c 6d c6 c8 7c cb 2c                          P<m..|.,
ssl_msg.c:1437: 0x7f9aa803d288: mbedtls_cipher_auth_decrypt() returned -25344 (-0x6300)
ssl_msg.c:3900: 0x7f9aa803d288: ssl_decrypt_buf() returned -29056 (-0x7180)   

Between each emission or reception of the fragment, the TLS security context is loaded and saved into a database. The use case here is really interesting, it seems to work well except when I receive or emit a message split into multiple fragments. Something is lost during the session backup.

Maybe an interesting thing to add is when I'm loading a TLS session from the database, I'm following these steps:
  • Load the session into a buffer from the database
  • Init a security session with mbedtls_ssl_init() and mbedtls_ssl_setup()
  • Load the session from the buffer with mbedtls_ssl_context_load()
Since I'm not an expert of mbed TLS code, I would like to know if someone could help me investigate this issue. TLS serialization/deserialization could be interesting to be part of the mbed TLS library.

Regards,
Jérémy Audiger