Hi all,
I have found that for TLS session resumption the master secret is needed (see
https://datatracker.ietf.org/doc/html/rfc5246#appendix-F.1.4). As such in general it should not be advised to remove the master secret from the SSL connection state.
Although session resumption is refactored under TLS v1.3 it is, as far as I see, still needed there.
So to conclude:
No need to optimize anything around the master secret as it is now, but it could be beneficial to add a pre-compiler option (because of the security constraints) to mbed TLS to disable session resumption. I could come up with a proposal for something like that.
Any thoughts on that?
Regards,
Maarten
From: Maarten Meijer via mbed-tls <mbed-tls@lists.trustedfirmware.org>
Sent: woensdag 11 mei 2022 15:47
To: mbed-tls@lists.trustedfirmware.org
Subject: [mbed-tls] Clear master secret from mbedtls_ssl_session after handshake is ready
Hi all,
I’m using an mbedTLS server on a CPU with a small memory foot print. In a search to serve as many as possible TLS clients, I found that the
mbedtls_ssl_session.master[48] structure member is still in memory after the handshake is over.
(I filed an issue to start with, but was quickly directed to this mailing list, thanks to Tom Cosgrove. See
Clear master secret from mbedtls_ssl_session after handshake is ready · Issue #5832 · Mbed-TLS/mbedtls (github.com))
I’m wondering why this is needed. The `master` secret references I can find in the code are either related to the TLS handshake, or to serialization/deserialization. I am wondering whether it makes sense to serialize/deserialize
the master secret but I’m not sure if it is a use case to support serialization of ongoing handshake operations.
Based on this 2 questions:
Looking forward for relevant answers. Thanks in advance,
Maarten