This caught my eye:
https://github.com/bagder/curl/blob/680d5fd/lib/vtls/curl_schannel.c#L914-L921

The documentation for DecryptMessage [1] says that if the function fails to decrypt the message several errors can be returned. For two of those errors handled in curl_schannel.c SEC_I_RENEGOTIATE/SEC_I_CONTEXT_EXPIRED the code is still reading the buffers as if there could be decrypted data like it's on the success path. I can't find DecryptMessage documented behavior to support that. Maybe some undocumented win2k thing?

[1]: http://msdn.microsoft.com/en-us/library/windows/desktop/aa375348.aspx

---
** [bugs:#1462] SSL connection returns garbage data**
**Status:** open
**Labels:** SSL DarwinSSL 
**Created:** Fri Dec 05, 2014 09:45 PM UTC by Tae Hyoung Ahn
**Last Updated:** Tue Dec 09, 2014 02:35 AM UTC
**Owner:** Daniel Stenberg
When curl receives encrypted data from ssl connection, schannel_recv() tries to decrypt.
If s_pSecFn->DecryptMessage() returns a error such as SEC_I_CONTEXT_EXPIRED, schannel_recv() returns ret variable that has the encrypted packet length not decrypted packet size.
So the last line of schannel_recv() should be changed to return size variable.
 
---
Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/
To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.