The log messages for SSL_ERROR_ZERO_RETURN and SSL_ERROR_SYSCALL are the same: "SSL network connection closed", as an error in 2.5.3 and at loglevel 3 in 2.5.4. Although this is true, the former case is a potentially normal, to be expected event in the lifetime of an SSL connection (particularly during the initial connect), whereas the latter is an unexpected condition (either an IO error, or an EOF in violation of the SSL protocol). Thus, the log behaviour in the two cases should reflect this, rather than conflating the two.

In previous versions, SSL_ERROR_ZERO_RETURN was logged as an error, whereas the LOG(3) is more appropriate. In this case, throwing a SocketException is not appropriate, since no actual error has occurred.

According to the SSL_get_error() manpage (1.0.1c, snippets below), in the case of SSL_ERROR_SYSCALL, if ret != 0, then we should use emit an error based on getSSLErrorMessage(ret) (like for SSL_ERROR_SSL).

However, if ret == 0, then if code == 0 (called ret in the manpage), then we should emit an error such as "SSL protocol violating EOF", otherwise if code == -1 then report errno before throwing the SocketException.

SSL_ERROR_ZERO_RETURN
    The TLS/SSL connection has been closed.  If the protocol version is SSL 3.0 or TLS 1.0, this result code
    is returned only if a closure alert has occurred in the protocol, i.e. if the connection has been closed
    cleanly. Note that in this case SSL_ERROR_ZERO_RETURN does not necessarily indicate that the underlying
    transport has been closed.

SSL_ERROR_SYSCALL
    Some I/O error occurred.  The OpenSSL error queue may contain more information on the error.  If the
    error queue is empty (i.e. ERR_get_error() returns 0), ret can be used to find out more about the error:
    If ret == 0, an EOF was observed that violates the protocol.  If ret == -1, the underlying BIO reported
    an I/O error (for socket I/O on Unix systems, consult errno for details).

Bonus points for swapping ret and code in SSLManager::_handleSSLError() so that they match OpenSSL's convention, avoiding confusion such as in the previous two paragraphs.