Hello, I'm debugging a problem with ucspi-ssl<http://www.superscript.com/ucspi-ssl/index.html>, an open-source SSL client and server wrapper. For the most part everything works great, but I am seeing strange shutdown behavior when using the client wrapper to connect to one particular server.
The client wrapper uses blocking socket BIOs in a select(2) loop. When it is time to cleanly close the connection, it calls SSL_shutdown(), then returns to its select loop to wait for a response indicating that the server has completed its end of the shutdown. When the server has completed the shutdown, it expects select to return with a readable socket, then calls SSL_read expecting it to return with SSL_ERROR_ZERO_RETURN. Next it calls SSL_shutdown() again to get the final status, then considers the connection closed and exits. That works nearly all the time. However, with this one particular server, after calling SSL_shutdown() the call to select(2) never returns. When I watch the program under strace(1), I can see the client sending some encrypted traffic to the server, and the server never sends a response. openssl s_client doesn't seem to exhibit this behavior; it looks like it calls SSL_shutdown() once, then closes the socket. Eric Rescorla's sclient OpenSSL example exhibits the same problem shutting down this SSL connection however. At the risk of annoying a mail server admin somewhere in the UK, I'll mention that the server in question is an SMTPS server at fl2494.globix.forlinux.co.uk, and appears to be running EXIM. Some quick tests indicate it might actually be all EXIM SMTPS servers. Given all this, I have two questions. First, is there something different I should be doing here to shut down the SSL connection? Second, is this pretty normal behavior in the wild, and do most SSL clients simply call SSL_shutdown() once and then close the socket to avoid hanging when this happens? Thanks for any advice! -----Scott.
