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.
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