After a first SSL3/TLS handshake has completed on an SSL socket, When you call SSL_ForceHandshake to drive a SECOND handshake through to completion, it calls ssl3_GatherCompleteHandshake() without first checking to see if there is already previously-received and decrypted SSL appliation data still sitting there in the "gather state" buffer, still unconsumed by the application. Consequently, any previously unconsumed appliation data sitting in that buffer is immediately lost. This function has always behaved this way. In the past, we've told users to use SSL_DataPending to see if there is unconsumed buffered received data, and if so, to read it all out before calling SSL_ForceHandshake (again). But I'm wondering (which is why I filed this bug as UNCONFIRMED) if the definition of SSL_ForceHandshake could be changed so that it checks for unconsumed read data and return immediately if such is found, and if such a change would break any existing users of SSL_ForceHandshake. I've been trying to think why (or HOW) a program would be dependent on this data-discarding behavior of SSL_ForceHandshake, and it's not obvious. Any thoughts?
I think - this really is a bug - it can be fixed without breaking any existing code that CORRECTLY uses SSL_ForceHandshake - I should fix it for 3.12 (if not sooner)
Unsetting target milestone in unresolved bugs whose targets have passed.