Nanno Langstraat wrote:
Can we agree on the convention that as long as no OpenSSL call has returned -1, there is no error condition in effect, at least as far as the application knows?

Nope. A return value of 0 from SSL_read() is also a special case. The same is true of the kernel call read(). No amount of calls to read data will yield any more data.

So now you should call SSL_get_shutdown() if you SSL_RECEIVED_SHUTDOWN is set then you at least received a graceful shutdown. If you did not you can presume the other end does not care for a secure shutdown (or the socket has some other error) so should close handles.


If you are still in play then at this point you know 100% you are never going to receive any more application data and that the remote end has gracefully initiated a secure shutdown. But... you are not sure if the sending side if the tcp socket you are holding is still open, if it is then you have the opportunity to send your secure shutdown.

At TCP level (if you have SIGPIPE ignored) when write() will return -1/EPIPE if the socket really is closed.


Now things start to get messy.

You want to instruct OpenSSL to attempt to commit a shutdown response and then write that response to the BIO layer. If the BIO layer accepts the data without any error then it was open and now you can tidy up knowing you got your graceful shutdown reply out. If it didn't then it will may return one of 2 things:

* the socket couldn't accept all the data just yet (EAGAIN) in this case you want to retry pushing that data out later (when the socket is writable). Or

* it may indicate some other error (like EPIPE) which is not recoverable, so you should tidy up.

It gets messy because the obvious way to implement it to me would be to call SSL_shutdown() and expect to get back -1/WANT_WRITE (meaning try again later) or 1 (meaning all done).

But I think the problem with SSL_shutdown() never returning -1 is very well known now, LOL.


Darryl
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@openssl.org
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to