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.