Antoine Pitrou wrote:
What I'm specifically interested in is SSL_ERROR_SYSCALL with errno==0.

I have investigated this issue of -1/SSL_ERROR_SYSCALL with errno==0.

From the SSL_get_error(3) man page:

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).

Note the use of "may contain more information" there is no guarantee.

Note the confirmation that ret==0 for the specific condition of EOF (on the BIO, i.e. on the socket, it violates the protocol because the protocol expects to receive a shutdown notify packet, which would have been caused by the far end calling SSL_shutdown() at least once). You have used the term "errno" where really OpenSSL talks in terms of the error codes off the error stack.

I also note the man page doesn't include SSL_shutdown() in the very specific list of calls that SSL_get_error() is used in sympathy with. However it was my intention to bring SSL_shutdown() into line so that man page should also be updated to include SSL_shutdown().

My claim is that the other end did a close() on the socket, while you were trying/sending/waiting-for the two-way SSL shutdown process to complete.

This would be observed as an end-of-file condition, i.e. read() returns 0.

This is considered a "SSL3/TLS1 protocol violation" because the protocol expects all users to always make use of the cryptographically secure two-stream shutdown all the time.

I have then taken a look at Python from CVS and see that:

./Modules/_ssl.c function PySSL_SetError() does attempt to handle SSL_ERROR_SYSCALL as per the documentation. Whoever wrote that did read the man page.

While I agree with the sentiment that having the exact errno saved and available for inspection/recall by the application using OpenSSL would be very useful. I don't agree that SSL_shutdown() is acting against the existing documentation.

Unfortunately I am not sure myself how errno values from read/write or recv/send calls get onto the OpenSSL error stack. Auditing the source reveals very few places where get_last_socket_error() is called in relation to normal recv/send IO operations. So I'm almost able to say it is not possible to retrieve errno values for anything other than the connect setup phase (where a variety of kinds of error can occur, ECONNREFUSED, ETIMEDOUT, ENETUNREACH, ... check out the connect(2) man page). This is also the stage most people have problems and therefore historically have required the most detail about the problem to resolve it.

There is however one mystery of how EPIPE from a write() is getting propagated back in Python, I can only think that Python's custom BIO is providing this information. As I can't see how OpenSSL's own socket BIO implementation does that. The strangeness of printing errno==0 out as a reason for an error is actually leaning towards a facet of Python's BIO layer and BIO error handling.


OpenSSL Project                       
User Support Mailing List          
Automated List Manager                 

Reply via email to