Girish Venkatachalam wrote:
But did you factor the fact that an SSL renegotiation
or handshake can happen anytime during the
conversation?
Thats not strictly true, the receiving end does have a tiny bit of
control over when to process it. From recent discussion in this list my
understanding in was improved on this matter.
In order for a renegotiation to take place, the receiving side must call
a receive processing function (SSL_read() / SSL_peek()) to allow the new
inbound data to be processed to be able to see the renegotiate request.
If you never call SSL_read()/SSL_peek() and aren't currently
processing a renegotiation request and don't instigate a renegotiation
request from your side. Then SSL_write() will never return WANT_READ.
This is because you don't allow the SSL library to process inbound data
in order to receive and decode the renegotiation request packet sent
from the other end.
While in this state the renegotiation stays outstanding at the remote
end and the request sits in the kernel buffer/lower BIO layer and the
SSL library itself wont know about it.
This situation is especially important to allow pipelined data
applications to work effectively over SSL. While you are in a bulk
writing phase you may not interested in processing any new inbound data
at this time. When you finish your bulk writing phase you go back to
processing inbound data. It is at that time you see and process reneg
request and deal with it.
If you were forced to always receive and process all inbound data at all
times then you'd have to have an infinitely large memory buffer to
temporarily store data you couldn't make use of right away (because you
were too busy writing data in the bulk writing phase of the operation).
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
