On 5/23/2011 1:59 AM, Harshvir Sidhu wrote:
David,
So are you suggesting that i change the approach in my Code.
Hard for me to give you a useful answer without seeing your code. If
your code tries to treat OpenSSL as a filter, expecting input and output
to correlate, then yes. If your code handled OpenSSL as a black box with
four separate I/O paths (encrypted data in, encryped data out, plaintext
in, plaintext out) without assuming any relationship between them, then
it's fine.
> My
application is for Windows and in Managed C++. In that i am using
Callback function for receive, when the callback function is called, and
when i call SSL_read in that, it hangs at recv call in the OpenSSL code,
my assumption is that data was already read from socket, when callback
was called. Another thing i would like to mention is I am using Sockets
Managed Class, not the native sockets.
When your callback function is called, that means encrypted data is
available on the socket. The SSL_Read function is for reading
unencrypted data from the SSL engine. It is only appropriate to call
SSL_Read in response to a data available callback on the socket in one
case -- if your last SSL operation was an SSL_Read and it returned a
WANT_READ indication. In any other case, this is broken behavior
reflecting erroneously trying to "look through" the SSL engine.
Your code must treat the SSL engine as a black box. Yes, we happen to
know that *IN* *GENERAL* we're reading encrypted data from the socket,
decrypting it, and then passing the plaintext to the application, your
code should treat this as an OpenSSL internal detail and should not
pretend it knows that this will happen.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
