Hi Hannes,

thank you for your answers.

I know that the behaviour is not defined by standard(s). My question was about the default behaviour of mbed TLS (>=3.0). - Will the connection kept online when the cert did expire and the application does not react (e.g. by doing a new handshake)? - Will this default behaviour be kept in future (at least for 3.x)?

For the second question: Cool. I actually forgot that 1.2 and 1.3 differ here. :-)

IMHO a somewhat reasonable approach could be that while connection is up the application at lower level should check regularly the cert and simply close the connection on expiration. Re-establishing the connection will then be done at higher level in our application. But maybe keeping the connection up could also be valid for us. Hence the questions.

Can anyone answer the third question about the private struct members?

kind regards, Frank

On Tue, Apr 26, 2022 at 01:57:30PM +0000, Hannes Tschofenig wrote:

Hi Frank,

Good questions. Let me focus on the first two questions.

The topic of long-lasting connections was discussed on the IETF TLS mailing list, see issue https://mailarchive.ietf.org/arch/msg/tls/vTxwj2iShME6c7AHg_Ub-_eS_fM/

In a nutshell, TLS does not say anything about what should be done when a certificate expires (or gets revoked) after the handshake has been completed and the connection still exists. It is up to the application to decide what to do. Of course, the application first needs to find out that the certificate has been expired (or revoked). How it does this is also application specific.

Regarding (2): The answer depends on whether you are using TLS 1.2 or TLS 1.3. In TLS 1.2 you would have to use session renegotiation and one has to check whether a different key can be configured (I don't know). For TLS 1.3 you have to use post-handshake authentication, which is not implemented in the Mbed TLS stack yet. Hence, you cannot use it (unless you help us add this functionality). From the TLS mailing list discussion you will, however, see that the entire idea of performing a re-authentication to check the authorization status is a bit dubious in the first place.

Ciao Hannes

-----Original Message----- From: Frank Bergmann via mbed-tls mbed-tls@lists.trustedfirmware.org Sent: Monday, April 25, 2022 12:47 PM To: mbed-tls@lists.trustedfirmware.org Subject: [mbed-tls] misc. questions

Hi all,

I have some questions.

1. If you have an established TLS connection (mbed TLS 3.x) and while the connection is up the (server-) certificate expires: Will the connection stay up? Or is a new handshake (with valid cert) REQUIRED?

2. Related to question 1: CAN mbed TLS switch to a new cert on an existing TLS connection? (e.g. by doing another handshake from server OR client side)

3. With 3.x some struct members are now "private". Even if you can allow private access by a define it would be better to use a getter. But for ssl context's "state" I am missing this and also for "p_bio" (to access fd). Is there a chance to get this implemented?

BTW - a big "LIKE" for 3.x! I really appreciate the changes. Thank you!

kind regards, Frank

-- mbed-tls mailing list -- mbed-tls@lists.trustedfirmware.org To unsubscribe send an email to mbed-tls-leave@lists.trustedfirmware.org

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,