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/aaabe86ac1f47193f4fc499846a0b3abeae…
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
Hello,
In Mbed TLS long-time support branches (currently 2.7.x and 2.16.x), we
make bug fixes, but we preserve backward compatibility as much as
possible. This means that as much as possible, we don't change existing
behavior unless it's definitely wrong, we don't add new APIs, we don't
increase the code size. We also preserve backward compatibility with
build and deployment processes for projects that use the library. We
don't create new source files, we don't change the name of makefile
targets, we don't add new tools requirements or tool version
requirements to build the library and its tests, etc. For example:
* We added Python as a requirement to build the tests shortly before
the 2.16 release, but kept the existing Perl script in the 2.7 LTS.
* We've changed config.pl to a Python script in development, but kept
it in Perl in LTS branches.
* We've dropped support for older Visual Studio version in
development, but kept it in LTS branches.
How far should this extend to non-core files, such as documentation and
higher-level test scripts? For example:
* We're considering tweaking the format of the ChangeLog file. Should
we preserve the format strictly in LTS branches?
* How about renaming ChangeLog to CHANGES or CHANGES.md?
* We're considering rewriting some multi-configuration test scripts
and maintainer sanity checks such as tests/scripts/depends-*.pl,
tests/scripts/all.sh, tests/scripts/check-names.sh, etc., in Python.
(Note that we've already done that with new scripts added to all.sh:
Python was not a requirement to pass all.sh in 2.7.0, but it is now.)
--
Gilles Peskine
Mbed TLS developer
Welcome to the Mbed TLS list @ TrustedFirmware.org!
This mailing list is the primary channel for public discussion, questions and announcements about the Mbed TLS project. Please use this where possible in preference to the GitHub issue tracker or private support channels. The GitHub issue tracker should still be used for raising bugs and enhancement requests (after first checking the issue doesn't already exist).
Thanks and regards
Dan.
Welcome to the Mbed TLS list @ TrustedFirmware.org!
This mailing list is the primary channel for public discussion, questions and announcements about the Mbed TLS project. Please use this where possible in preference to the GitHub issue tracker or private support channels. The GitHub issue tracker should still be used for raising bugs and enhancement requests (after first checking the issue doesn't already exist).
Thanks and regards
Dan.