Hi Dmitrii!

The reason why we focused on DTLS 1.2 + AEAD for the context serialization was because that's
what we needed to support quickly at the time, and not because we saw some fundamental
technical obstacles in implementing context serialization for TLS 1.2.

I did the same as you, commenting out DTLS checks, and ran into the same problem during
`mbedtls_cipher_auth_decrypt()`. The problem turns out to be the following: In TLS, the 
context contains an incoming record counter which, while in DTLS, the record counter
is explicit and hence need not be maintained. 

In particular, when using the current serialization+deserialization functions with TLS 1.2,
the incoming record counter will be corrupted. 

The core of the fix is simple: You need to duplicate https://github.com/ARMmbed/mbedtls/blob/development/library/ssl_tls.c#L6228-L6233
and https://github.com/ARMmbed/mbedtls/blob/development/library/ssl_tls.c#L6496-L6500 -- which save/load the _outgoing_ counter --
for the incoming counter `ssl->in_ctr`. I just tried this and things worked afterwards.

Could you try and see if it works for you, too? If so, please feel free to adapt the serialization
functions and file a PR to add support for serialization in TLS, and mark me as a reviewer.

Note: There will likely be other things that need fixing, too, so please be careful in
using the above patch as-is unless for experimentation.

Cheers,
Hanno

From: mbed-tls <mbed-tls-bounces@lists.trustedfirmware.org> on behalf of Kuvaiskii, Dmitrii via mbed-tls <mbed-tls@lists.trustedfirmware.org>
Sent: Tuesday, March 31, 2020 8:58 PM
To: mbed-tls@lists.trustedfirmware.org <mbed-tls@lists.trustedfirmware.org>
Subject: [mbed-tls] TLS context serialization: can it be done?
 
Dear all,

I have the following question. mbedTLS v2.21.0 has support for TLS context serialization in the form of two functions: `mbedtls_ssl_context_save()` and `mbedtls_ssl_context_load()`. I'm trying to use these functions in another project (Graphene, an Intel SGX framework). Slightly oversimplifying, I want to establish a secure communication channel between two different Linux processes. I'd like to persist one of them and then re-spawn it again with the communication channel intact (so that there is no need for a new TLS handshake).

However, I notice that currently these functions support only DTLS 1.2, see e.g.: https://github.com/ARMmbed/mbedtls/blob/aaabe86ac1f47193f4fc499846a0b3abeae9207b/library/ssl_tls.c#L5954

But I want to use a normal TLS channel, in particular with a ciphersuite `MBEDTLS_TLS_PSK_WITH_AES_128_GCM_SHA256`.

I commented out the checks on DTLS in these functions just to see what will happen. As expected, both functions serialized and then deserialized the context, but when doing a `write(ssl_ctx)` in one (not-persisted) process  and a `read(loaded_ssl_ctx)` in another (re-spawned) process, I get an error in `mbedtls_cipher_auth_decrypt()`. Clearly, my deserialized context didn't restore some vital information on the TLS session, and this led to failure in decryption.

Thus, I have two questions:
1. Is there any version of this code that also works on TLS?
2. What are the additional internal objects that must be serialized for TLS (if it makes things easier, in my particular case with AES-GCM and a pre-shared key)? I looked at the code and tried to dump more fields in `mbedtls_ssl_transform`, but it didn't help much. If you'd provide me with some pointers, I could tinker more with mbedTLS code and hopefully make it work.

Thanks in advance for any pointers!

--
Dmitrii
--
mbed-tls mailing list
mbed-tls@lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
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.