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-... and https://github.com/ARMmbed/mbedtls/blob/development/library/ssl_tls.c#L6496-... -- 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/aaabe86ac1f47193f4fc499846a0b3abeae9...
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.
Dear Hanno,
Thank you for the explanations! I came to the same implementation yesterday after some extensive testing.
Just for reference, I created a repo with my testing environment: https://github.com/dimakuv/mbedtls-psk-example. The diff with a quick-and-dirty fix to mbedTLS 2.21.0 is here: https://github.com/dimakuv/mbedtls-psk-example/blob/master/mbedtls-2.21.0.di....
I'll be happy to contribute this (with proper macros, updated comments, etc.) to mbedTLS. Should I base my PR on the "development" branch? Also, how should it be tested, with a couple default config.h configurations?
-- Dmitrii
From: Hanno Becker Hanno.Becker@arm.com Sent: Thursday, April 2, 2020 12:58 AM To: mbed-tls@lists.trustedfirmware.org; Kuvaiskii, Dmitrii dmitrii.kuvaiskii@intel.com Subject: Re: TLS context serialization: can it be done?
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-... and https://github.com/ARMmbed/mbedtls/blob/development/library/ssl_tls.c#L6496-... -- 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.orgmailto:mbed-tls-bounces@lists.trustedfirmware.org> on behalf of Kuvaiskii, Dmitrii via mbed-tls <mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org> Sent: Tuesday, March 31, 2020 8:58 PM To: mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org <mbed-tls@lists.trustedfirmware.orgmailto: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/aaabe86ac1f47193f4fc499846a0b3abeae9...
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.orgmailto: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.
Dear Dmitrii,
PR https://github.com/ARMmbed/mbedtls/pull/2791 introduced testing for the existing DTLS serialization functionality, so if you make sure that the tests introduced there are replicated also for the TLS serialization, that's a good start for sure. The relevant test changes are in `all.sh`, `ssl-opt.sh`, `test_suite_ssl.function` and `ssl_client2.c` and `ssl_server2.c`.
That said, if you feel it's tricky to find your way through the test system, feel free to do as much as you can, open a PR, and we'll take it from there.
The PR should be based on `development`.
Cheers, Hanno ________________________________ From: Kuvaiskii, Dmitrii dmitrii.kuvaiskii@intel.com Sent: Thursday, April 2, 2020 4:23 PM To: Hanno Becker Hanno.Becker@arm.com; mbed-tls@lists.trustedfirmware.org mbed-tls@lists.trustedfirmware.org Subject: RE: TLS context serialization: can it be done?
Dear Hanno,
Thank you for the explanations! I came to the same implementation yesterday after some extensive testing.
Just for reference, I created a repo with my testing environment: https://github.com/dimakuv/mbedtls-psk-example. The diff with a quick-and-dirty fix to mbedTLS 2.21.0 is here: https://github.com/dimakuv/mbedtls-psk-example/blob/master/mbedtls-2.21.0.di....
I’ll be happy to contribute this (with proper macros, updated comments, etc.) to mbedTLS. Should I base my PR on the “development” branch? Also, how should it be tested, with a couple default config.h configurations?
--
Dmitrii
From: Hanno Becker Hanno.Becker@arm.com Sent: Thursday, April 2, 2020 12:58 AM To: mbed-tls@lists.trustedfirmware.org; Kuvaiskii, Dmitrii dmitrii.kuvaiskii@intel.com Subject: Re: TLS context serialization: can it be done?
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-...
and https://github.com/ARMmbed/mbedtls/blob/development/library/ssl_tls.c#L6496-... -- 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.orgmailto:mbed-tls-bounces@lists.trustedfirmware.org> on behalf of Kuvaiskii, Dmitrii via mbed-tls <mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org> Sent: Tuesday, March 31, 2020 8:58 PM To: mbed-tls@lists.trustedfirmware.orgmailto:mbed-tls@lists.trustedfirmware.org <mbed-tls@lists.trustedfirmware.orgmailto: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/aaabe86ac1f47193f4fc499846a0b3abeae9...
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.orgmailto: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.
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.
mbed-tls@lists.trustedfirmware.org
-
Hanno Becker -
Kuvaiskii, Dmitrii