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
Hi Jeremy,
Thank you for your reply.
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().
Note that you're talking about the SSL context here, not the SSL session, which the thread asked about. That said, we're intending to make the SSL context internal as well, so your feedback is very valuable.
For the SSL handshake state: I agree that we will likely want to introduce a getter function for this as we make the SSL context internal and have created https://github.com/ARMmbed/mbedtls/issues/4383 to track this.
For the CID, I am not following your use case yet: sslContext.own_cid is what you configure yourself via mbedtls_ssl_conf_cid(), so there's no need to query it from the context. The CID that the peer requested can be queried via mbedtls_ssl_get_peer_cid(), as you say. Does that make sense?
Regards, Hanno
________________________________ From: Jérémy Audiger jeremy.audiger@ioterop.com Sent: Monday, April 19, 2021 5:42 PM To: mbed-tls@lists.trustedfirmware.org mbed-tls@lists.trustedfirmware.org; Hanno Becker Hanno.Becker@arm.com Subject: Re: SSL session cache API in Mbed TLS 3.0
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
mbed-tls@lists.trustedfirmware.org
-
Hanno Becker -
Jérémy Audiger