> From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> on behalf of John Unsworth <John.Unsworth@xxxxxxxxxxxxxxx> > 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
