[EMAIL PROTECTED] wrote:
> I have an application which is occasionally hanging. I have tracked it
> down to an SSL_shutdown call.
There is an issue with SSL_shutdown() on non-blocking sockets in respect
of knowing when to use the shutdown() call.
I'm not exactly sure if you have run into this problem, since you did
not say if your application uses the system call shutdown() at all. If
it doesn't then disregard the rest of this email.
Can you confirm if your application uses the shutdown() system call at all ?
If it does:
* at what time does it call it in respect of using the socket for SSL
and the other OpenSSL API calls ?
* how is it used, as shutdown() can be called to shutdown one half of
the communication, which half to you shutdown and when (in respect of
OpenSSL API calls) ?
The problem that I am aware of is that when using SSL_shutdown() to emit
a shutdown_notify packet (part of the SSL/TLS protocol spec) it is not
clear when the entire data for the packet has made it into the kernel
buffer, as the usual WANT_READ and WANT_WRITE mechanism are not convey
to the application correctly with the usualy -1 error return.
I have created a path that fixes this problem (which does the following) :
* Makes SSL_shutdown() return -1/WANT_WRITE if the initial call(s) to
SSL_shutdown() are unable to commit the entire shutdown_notify packet
into the kernel buffer / BIO layer.
* It only returns 0 once just after the moment when the
shutdown_notify packet has just been committed by this invocation of
SSL_shutdown(). At this point in time the application may now call
shutdown(fd, SHUT_WR) because OpenSSL has no further use for writing to
the socket anymore.
* Subsequent calls to SSL_shutdown() now return -1/WANT_READ when it
has sucessfully return 0 previously but it still has not received the
incoming shutdown_notify from the remote end.
* Upon recving the shutdown_notify packet from the remote end
SSL_shutdown() now return 1. At this point in time the application may
now call shutdown(fd, SHUT_RD) or close(fd) since OpenSSL has not futher
use for reading or writing to the socket anymore.
My patch does not change the way SSL_shutdown() work in relation to the
man page it still returns 0 and 1 but it also can now return
-1/WANT_WRITE and -1/WANT_READ to indicate what OpenSSL is waiting on to
push through the SSL_shutdown() instruction to the next stage.
If you think this related to your problem, please examine the previous
discussion (hope the links still work) :
http://marc.info/?t=115099728200002&r=1&w=2
http://marc.info/?t=115154004000001&r=1&w=2
http://marc.info/?t=115129081200001&r=1&w=2
http://marc.info/?l=openssl-dev&m=116525974320575&w=2
http://marc.info/?l=openssl-dev&m=115153998821797&w=2
http://marc.info/?l=openssl-dev&m=115153957132635&w=2
and comment back to the list on how your situation relates to this.
The value (0) returned from the shutdown call indicates that the
shutdown is not finished. The shutdown man page indicates that a second
call to SSL_shutdown should cause a bidirectional shutdown, and I
thought this is indeed what the application calls for. However, when I
make the second call to SSL_shutdown, the value returned is still 0
(shutdown not finished) rather than 1 (shutdown complete) or -1
(shutdown not successful).
Is this recently added bahavior? Does the SSL handle need to have
certain properties in order to get a bidirectional shutdown?
No it has always done this. The stickyness of returning "0" is a
failure (IMHO) in the existing release code. Since "0" is meaningless
as the application doesn't know if its waiting to read or write and the
application NEEDS to know that in order to know how to wait on the
non-blocking socket for it to change state so that SSL_shutdown() can be
called again.
The application also NEEDS to know at the earliest point in time when
shutdown(fd, SHUT_WR) may be called. At the moment its just not
possible to know when to call it since at the point in time
SSL_shutdown() does return 1 you might as well call close(fd).
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
