Hi,
our goal is to do a renegotiation on an existing connection with an updated cert. MBEDTLS_SSL_RENEGOTIATION_ENABLED was configured (client&server) and mbedtls_ssl_conf_renegotiation_enforced() was NOT enabled.
When calling mbedtls_ssl_renegotiate() we always got MBEDTLS_ERR_SSL_WAITING_SERVER_HELLO_RENEGO. How can we deal with this? How can we "finish" the renego?
Code looks somewhat like this:
while ( (ret=mbedtls_ssl_renegotiate(&ssl)) != 0) { if ((ret!=MBEDTLS_ERR_SSL_WANT_READ) && (ret!=MBEDTLS_ERR_SSL_WANT_WRITE) && (ret!=MBEDTLS_ERR_SSL_WAITING_SERVER_HELLO_RENEGO)) { ... // handle error } ++c; if (c==30) { ... // exit with error } sleep(1000); }
kind regards, Frank
On 28.04.22 23:07, Gilles Peskine via mbed-tls wrote:
Hi Frank,
As others have already replied, a TLS connection is not limited by the certificate used to authenticate the server (if any). More generally, the connection is not bound to the certificate. Once the handhsake is over, the client does not need to remember how it verified the server's identity.
Mbed TLS does not keep the handshake data (including certificates) after the handshake is over, and does not have any mechanism to automatically close a connection after a given amount of time. If you want to renew the server authentication periodically based on the certificate, you would need to set up a callback to read the certificate data with mbedtls_ssl_set_verify() and call mbedtls_ssl_close_notify() when you want to stop using the connection. (Renegotiation instead of a new connection might be an option in TLS 1.2.) Please note that I find this a weird requirement and I would push back on it. If you want to re-authenticate the server regularly, I suggest closing the connection when idle or regularly based on a client-side policy, and not linking this to the server management policy of certificate renewal.
Regarding private struct members, we've identified the loss of knowledge about the state as a problem in some applications. We've decided not to add a getter for the state, because the states are tricky to use, do not take renegotiation into account in TLS 1.2, and are different between TLS 1.2 and 1.3. See the discussions in https://github.com/Mbed-TLS/mbedtls/issues/5331 and https://github.com/Mbed-TLS/mbedtls/issues/4383 . Instead we're adding new callbacks and new functions such as mbedtls_ssl_is_handshake_over(), which will be in the next release (no date set yet). For p_bio, it's just the value set by mbedtls_ssl_p_bio so I don't understand why an accessor would be useful. If your application has multiple SSL contexts and you want to tie an SSL context to application data structures, the user data pointer (mbedtls_ssl_set_user_data_p(), mbedtls_ssl_get_user_data_p()) (also to be in the next release) may be useful.
If you have a use case for accessing structure fields which is still not covered in the development branch or by an open issue (https://github.com/Mbed-TLS/mbedtls/issues), especially those in the Mbed TLS 3.2 epic (https://github.com/orgs/Mbed-TLS/projects/1#column-18338314), please open an issue on GitHub and let us know what you need and why.
Best regards,