Dealing with SEC_I_RENEGOTIATE and TLS1_ALERT_NO_RENEGOTIATION in SChannel

Question

I'm working with SChannel at the moment for an async (IOCP) based server and I've got most things working fine but I'm having a problem with renegotiation. Specifically, when peer A sends peer B a request to renegotiate and peer B responds with an TLS1 NO RENEGOTIATION alert how does peer A continue? I seem to have an invalid context at the point where I get the SEC_I_NO_RENEGOTIATION response and this prevents me from being able to continue to use the stream...

Updated I've done some more testing and it doesn't seem to be an invalid context but I do get SEC_E_ENCRYPT_FAILURE from the next call to Encrypt...

Is a request to renegotiate actually denyable? Or is NO RENEGOTIATION alert simply an informative error message which now means that the connection is useless? If so, why is it commented as being a 'warning' rather than an 'error'?? Nope; the TLS RFC (5246) clearly states that its up to the peer to decide if we can continue after a no renegotiation alert...

Updated It doesn't make any difference if I send the TLS alert using ApplyControlToken() or if I send it using EncryptMessage() with SECQOP_WRAP_OOB_DATA...

Answer 1

There was a HOTFIX issued for this a while back for Intel AMT based hardware. Essentially, the root certificate was stored as an SHA-1 hash instead of caching the entire certificate. SSPI passes all certificates EXCEPT the root, expecting the root to have this certificate for trust-chain verification. When the full root didn't exist, SSPI was forcing a re-negotiate.

The hotfix updates schannel on Win 2003 systems with Intel AMT installed.

Check out this KB: http://support.microsoft.com/kb/942841