How to handle a SEC_I_RENEGOTIATE received in TLS 1.3 Negotiation

Question

I have a client application that uses SCHANNEL to negotiate TLS 1.1 and TLS 1.2 which has worked for years. I recently changed to use SCH_CREDENTIALS and it still works for TLS 1.2 (and I presume TLS 1.1) on Windows 10. When run on Windows 11, it attempts TLS 1.3 as expected and desired. However, it fails when SCHANNEL returns a SEC_I_RENEGOTIATE status. This status confuses me because my understanding is that renegotiations was removed from 1.3 due to security concerns. (I never had to implement it in for 1.1 or 1.2.) In the Microsoft Security blog https://www.microsoft.com/en-us/security/blog/2020/08/20/taking-transport-layer-security-tls-to-the-next-level-with-tls-1-3/ , which talks about upgrading to TLS 1.3, the author says to make the upgraded code correctly handles the SEC_I_RENEGOTIATE status but gives no hint as what it should do.

Please provide some information about what to do with the SEC_I_RENEGOTIATE status.

Answer 1

I also suffered from the same problem.

If SEC_I_RENEGOTIATE is received when using TLS1.3

1.Prepare OutSecBuff and InSecBuff and pass the received data to InitializeSecurityContext.

2-1 If SEC_E_OK and there is no SECBUFFER_EXTRA buffer in OutSecBuff, receive the next packet and call Decryptmessage.

2-2 If SEC_E_OK and OutSecBuff has a SECBUFFER_EXTRA buffer, pass the SECBUFFER_EXTRA buffer to Decryptmessage.

If you are still looking for this information, please let me know your results.

Regards,

poca256