Darryl Miles wrote:
2) SSL_read() already has a return value -1/ZERO_RETURN which indicates end-of-stream. You may then call SSL_shutdown() to look to see if 1 is returned or not. Or even SSL_get_shutdown() and take whatever security action your application needs to take in the event of an improperly shutdown stream.
This isn't quite true. I turn off readahead at my initial call to SSL_shutdown() with SSL_set_read_ahead(ssl, 0).
Then in my event processor which runs off the readability indicator for the socket that is being shutdown in this handler I call SSL_shutdown() first but if it is still returning 0, I then call SSL_read() a number of times to sink the application data that may exist, I then call SSL_shutdown() again (before processing the last error if there was one to SSL_read()).
Turning the read_ahead off may not be necessary for you, I do it because in my app its possible to see unencrypted data behind the last SSL byte (or possible another request to setup a new SSL session).
I also only allow SSL_read() to be called a handful of times (in the shutdown handling detailed above) in a tight loop before it returns back to a main event loop this is to stop a form of denial of service where the receiving CPU is lower spec to the sending CPU which may cause starvation of other connections, this would be because its sinking the data and there isn't the usual disconnection due to too much invalid data that you'd get if it were in the main event loop doing request processing. Turning readahead off ensures OpenSSL only reads just as much data as it needs to and my readability events stay armed within the BIO layer if I choose to not read application data to exhaustion.
Darryl ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
