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