Further amendment to #114

[kentcb]

Alas, I was correct in saying I had seen SEC_E_BUFFER_TOO_SMALL being returned by InitializeSecurityContext. Here is a stack trace from my user:

System.ComponentModel.Win32Exception: The buffers supplied to a function was too small
   at Waffle.Windows.AuthProvider.WindowsSecurityContext.Initialize(SecHandle credentials, String targetName, Int32 fContextReq, Int32 targetDataRep, SecHandle context, SecBufferDesc continueTokenBuffer)
   at Waffle.Windows.AuthProvider.WindowsSecurityContext.Initialize(SecHandle credentials, String targetName, Int32 fContextReq, Int32 targetDataRep)
   at Waffle.Windows.AuthProvider.WindowsSecurityContext..ctor(String targetName, WindowsCredentialsHandle credentials, String securityPackage, Int32 fContextReq, Int32 targetDataRep)
   at Waffle.Windows.AuthProvider.WindowsSecurityContext.GetCurrent(String package, String targetName, Int32 fContextReq, Int32 targetDataRep)

Thus, I have re-added the code that treats SEC_E_BUFFER_TOO_SMALL the same as SEC_E_INSUFFICIENT_MEMORY. I realize MSDN does not indicate this error is possible from that function, but it certainly is. I have already tested the above change for my user, and all is good.

It would probably be good for someone to update the Java code too...?

[dblock]

I don't think we should merge it. First, I do think that we should make the change in all the code, .NET and Java if they were to be, but furthermore I think we should figure out why this is returning an error that is not documented in MSDN. In my experience this has been a side effect of a bigger problem :)

[kentcb]

I will have to run with my own patched version then. I have returned to Australia so it's impossible for me to diagnose further with the user in question (not that I'd have any ideas how to pin this down any further than it already is). I work for an investment bank, and you wouldn't believe the hoops I have to jump through to do this stuff.

[dblock]

I understand, thx @kentcb.

[wbond]

I just wanted to chime in here with some info I found. I've been working on a separate project that integrates with SChannel and InitializeSecurityContext and have also occasionally seen SEC_E_BUFFER_TOO_SMALL.

Through various testing, I've tracked it down to the ServerKeyExchange handshake message that is sent from the server to the client for DHE_RSA cipher suites. That is:

• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384

Sometimes a server will send a value for dh_Ys from https://tools.ietf.org/html/rfc5246#page-51 with a byte encoding that is one byte less than other times. This appears to be instances where the public integer can be encoded in a shorter byte string. In these situations, SChannel returns a SEC_E_BUFFER_TOO_SMALL error.

I've confirmed this to happen on Windows 7 and Windows 8.1. I have not confirmed on Windows 10 yet.

It seems the solutions to this include:

• Restart the TLS connection (there is a very high chance the new exchange will not experience this issue)
• Don't enable TLSv1.2, instead just TLSv1.1

[dblock]

Thanks @wbond. I am fine merging this, @kentcb could you update CHANGELOG and squash these commits?

[hazendaz]

This has been merged on bdc8ca5