David Schwartz wrote:
If I'm misunderstanding the man page and/or the source code
please speak up.
My man page says:
If the underlying BIO is non-blocking, SSL_shutdown() will also
return
when the underlying BIO could not satisfy the needs of SSL_shutdown()
to continue the handshake. In this case a call to SSL_get_error()
with
the return value of SSL_shutdown() will yield SSL_ERROR_WANT_READ or
SSL_ERROR_WANT_WRITE. The calling process then must repeat the call
after taking appropriate action to satisfy the needs of
SSL_shutdown().
The action depends on the underlying BIO. When using a non-blocking
socket, nothing is to be done, but select() can be used to check for
the required condition. When using a buffering BIO, like a BIO pair,
data must be written into or retrieved out of the BIO before being
able
to continue.
My man page comes from Red Hat, 0.9.8a-5.4, Sep 28, 2006.
Yes but what SSL_shutdown() actually does is always return 0, in cases
where the above man page states it should return -1/WANT_{READ,WRITE}.
Please compare the man page to my semantics at:
http://marc.info/?l=openssl-dev&m=115153998821797&w=2
and tell me where I'm being contradictory to the documentation.
Now audit SSL_shutdown() before my PATCH2 and after my PATCH2 and see
how the -1 error returns are thrown away in possible scenario where -1
should be returned. In these cases 0 is always returned (which is not
what the man page states should be returned).
The operations of SSL_shutdown() are as following in the following order
of events:
* Flag that SSL_shutdown() has been called at least once, so that any
future calls to SSL_write() will always fail, thats becomes an
application error. [This can operation never fail.]
* Flush all outstanding encrypted application data to the BIO layer,
if there is any. [This can fail (EAGAIN) and should return
-1/WANT_WRITE, I can't remember if this is error is propagated or not]
* Write and flush the "send shutdown notify" packet to the BIO layer.
[This can fail (EAGAIN) and should return -1/WANT_WRITE, but IIRC it
never does from this point onwards 0 is always returned by future calls
to SSL_shutdown(), I propose the first time this was successful and
-1/WANT_READ would ordinarily be returned (due to failure in the next
step) then the 0 is returned, this marks this significant and important
event has been passed on the road to shutting down. The next time
SSL_shutdown() is called and we are still in the waiting for "recvd
shutdown notify" packet mode then -1/WANT_READ shall be returned instead.]
* Then attempt to read the "recvd shutdown notify" packet. [This can
fail, in that we have not seen the packet yet and should return
-1/WANT_READ, but IIRC it never does, it returns 0.]
* Flag the "recvd shutdown notify" packet has been seen so that any
future calls to SSL_read() will always fail. [This operation can never
fail.]
The above operations must be restartable and its important for the
SSL_shutdown() to indicate to the application if/when the it passes the
3rd point above, since the application may wish to do important stuff
with regards to the write side of the BIO (shutdown(fd, SHUT_WR) or
FD_CLR(fd, &fdwrite) forever more).
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
