Hi Hanno,
Regarding your first point, I'm not against having the structure mbedtls_ssl_session as opaque on the application side, at least, it ensures the application is not modifying something that it shouldn't. Having said that, on my side, I access three fields of this structure:
* sslContext.state * sslContext.own_cid_len * sslContext.own_cid
The first one is used to retrieve the current state, mainly MBEDTLS_SSL_HANDSHAKE_OVER, MBEDTLS_SSL_SERVER_HELLO_VERIFY_REQUEST_SENT. Finally, the match between an incoming LwM2M Client encrypted message using CID and the structure mbedtls_ssl_session is done by accessing own_cid / own_cid_len. But I think this one could be done using mbedtls_ssl_get_peer_cid().
Regards, Jérémy ________________________________ From: mbed-tls mbed-tls-bounces@lists.trustedfirmware.org on behalf of Hanno Becker via mbed-tls mbed-tls@lists.trustedfirmware.org Sent: Friday, April 16, 2021 06:37 To: mbed-tls@lists.trustedfirmware.org mbed-tls@lists.trustedfirmware.org Subject: [mbed-tls] SSL session cache API in Mbed TLS 3.0
Hi Mbed TLS enthusiasts,
For Mbed TLS 3.0, we're considering to modify the API around SSL sessions and server-side SSL session caches as follows:
1) The mbedtls_ssl_session structure becomes opaque, that is, its layout, fields, size is not part of the API and thus not subject to any stability promises.
Instances of mbedtls_ssl_session may only be accessed through public function API. At the time of writing, this is mainly mbedtls_ssl_session_load()/save() for session serialization and deserialization. In particular, user code requiring access to specific fields of mbedtls_ssl_session won't be portable without further adjustments, e.g. the addition of getter functions.
If you access fields of mbedtls_ssl_session in your code and would like to retain the ability to do so, now is the time to speak up and let us know about your use case.
2) The SSL session cache API gets modified as proposed in https://github.com/ARMmbed/mbedtls/issues/4333#issuecomment-820297322:
int mbedtls_ssl_cache_get( void *data, unsigned char const *session_id, size_t session_id_len, mbedtls_ssl_session *dst_session );
int mbedtls_ssl_cache_set( void *data, unsigned char const *session_id, size_t session_id_len, mbedtls_ssl_session const *session );
In words: The session ID becomes an explicit parameter.
This modification is necessary because the present session cache API requires custom implementations to peek into the mbedtls_ssl_session structure, at least to inspect the session ID. With the session ID being added as an explicit parameter, this is no longer necessary.
We propose that custom session cache implementations treat mbedtls_ssl_session instances opaquely and only use them through the serialization and deserialization API mbedtls_ssl_session_load()/save(). The reason why the proposed API does not operate on serialized data directly is that this would enforce unnecessary copies.
If you are using a custom SSL server-side session cache implementation which accesses fields other than the session ID and which can not be implemented based on session serialization, now is the time to speak up and let us know about your use case.
Kind regards, Hanno