laudrup/boost-wintls

The function completed successfully, but must be called again to complete the context

gitgitwhat opened this issue · 7 comments

While I didn't solve the teardown issue in #22 yet, I can still get it to compile by commenting out the assert. When I do and run the code example I provided, the handshake call fails.

ws.next_layer().handshake(boost::wintls::handshake_type::client);
SEC_I_CONTINUE_NEEDED:  The function completed successfully, but must be called again to complete the context

In Wireshark, I can see the client and server hello along with the encrypted handshake message but immediately after that a RST packet is sent.

That is most definitely a bug in the handshake code. The code should call the relevant function continuously while this is returned.

Could you please see if you could provide a packet dump (PCAP file or similar) of the connection? Then I'll try to have a look at when time allows.

Thanks for taking the effort to provide such detailed bug reports

No worries. PCAP is attached. I'll let you know if I figure it out but Microsoft's documentation isn't really helpful in pinning down the actual reason for the error.

wintls.zip

I've had quick look at the code as well as the documentation.

This is a bit weird since the code doesn't seem to handle SEC_I_CONTINUE_NEEDED at all, although that is documented to be a normal return value from the InitializeSecurityContext function so I cannot understand how I have gotten around to not handle that.

I need to look deeper into this when I have the time, but it seems like you've found a pretty critical bug so thanks a lot for that.

I haven't been able to figure it out so I just bit the bullet and went back to OpenSSL. Thanks for your help but feel free to close the issue if you want.

I'm sorry to hear that, but that is of course perfectly understandable.

The Windows API in general and the SChannel/SSPI functionality in particular is extremely painful and difficult to use, so I'm honestly not that surprised that you haven't found a solution.

I will definitely not close this issue as this is indeed a real bug you've found and thanks a lot for that.

While I understand your decision to move on using OpenSSL I hope you'll continue to watch this project and consider giving it another shot once I've figured out a solution to this bug.

It's a lot more fun to write code that has some actual users :-)

Thanks once again.

I am fairly certain I have fixed the issues in 534db5a and 0e078b8, at least that makes the websocket client code you've sent me work.

As far as I can tell it turns out to be related to the encryption ciphers the server you test against use which reveals some real severe bugs in my code.

I would like to find out a way to automate tests to find issues like that, but in reality there's no way to find actual bugs without having it tested in the real world.

So thanks a lot for finding this issue and I hope you might want to try using this library again.

I assume this issue has been fixed, so I'll close it for now.