SSL_read() returning SSL_ERROR_SYSCALL with errno 11EAGAIN

[Michael Wojcik]

> From: openssl-users <openssl-users-bounces at openssl.org> on behalf of John Unsworth <John.Unsworth at synchronoss.com>
> Sent: Monday, April 29, 2019 10:54

> We are using OpenSSL 1.1.0h on Linux to send operations to LDAP servers. We use SSL_read()
> to receive the replies on a non-blocking socket. The vast majority of times SSL_read()  returns >0,
> SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE as per the spec. However we are very
> occasionally seeing SSL_ERROR_SYSCALL with errno 11 (EAGAIN) which would seem to be the
> result of a platform socket read(() or write() when blocking would occur. Is this expected
> behaviour? We have changed our code to treat this as SSL_ERROR_WANT_READ or
> SSL_WANT_WRITE depending on the result of SSL_want_write(). Are we correct?
 
I haven't seen a reply to this, so I'll take a stab...

I haven't looked at the code, but my impression is that WANT_READ and WANT_WRITE are returned in two cases: when OpenSSL has received or sent a partial record and needs to complete it; or when the TLS state is such that OpenSSL needs to perform the associated operation and it hasn't been requested by the application - for example, if the application is trying to receive data but OpenSSL needs to send renegotiation information.

If you do a non-blocking receive at a record boundary (so you don't have an incomplete record) and OpenSSL doesn't currently need to send for TLS reasons, OpenSSL will see the EAGAIN (or EWOULDBLOCK, depending on platform). I think in this case it does just return SSL_ERROR_SYSCALL, because OpenSSL itself doesn't "want" to receive. If OpenSSL had already received a partial record, then you'd get WANT_READ.

I suspect you could always treat this as WANT_READ, which typically means using a mechanism such as select or poll to determine when the socket is readable, then trying the OpenSSL receive again. But looking at the return value of SSL_want_write() seems safe enough.

That's my understanding. Someone else may know better.

-- 
Michael Wojcik