SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN

[John Unsworth]

>> I think that's an application bug.  
Thanks.
I thought you might say that. I will change the code and get the customer to retest.

Regards,
John

-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Viktor Dukhovni
Sent: 02 May 2019 18:23
To: openssl-users at openssl.org
Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN

CAUTION: This email originated from outside of Synchronoss.


On Thu, May 02, 2019 at 04:10:31PM +0000, John Unsworth wrote:

> > Do you wait for the non-blocking connect to complete at this point?
> We connect in blocking mode then switch to non-blocking.

Thanks that rules connection setup out of the picture.

> > Are multiple threads writing to the same SSL connection?  How do you 
> > ensure orderly use of the SSL connection?  Sharing connections 
> > across threads without application level synchronization is not 
> > supported in OpenSSL.
>
> We use mutexes to synchronize of course.

OK.

> > How are further requests locked out when you're performing reads?
> > What is the granularity of the relevant locks?
>
> The mutex only allows one SSL call at a time.

So a serialized mix of reads and writes with possibly multiple outstanding writes interleaved with the reader?  Right?

> > At this point you'd be calling SSL_get_error(), is there a lock that 
> > prevents writes between SSL_read() and SSL_read() and SSL_get_error()?
>
> The mutex does not protect SSL_get_error() calls.

I think that's an application bug.  The SSL_get_error() is using the same SSL handle as the SSL_read(), which can be materially altered by concurrent writes.  (Matt, if you're still reading this thread, do you agree?)

I would not release the mutex until after the call to SSL_get_error().

> > I gather the protocol is full-duplex and multiple outstanding 
> > requests can be written before the corresponding replies are read?  
> > Or is it strict half-duplex request-response?
>
> It is full duplex and there can be multiple operations in progress.

Please retest with both the SSL_read() and SSL_get_error() running under a single lock.  And similarly on the write side.

Do keep in mind that a server may close the socket for further writes after replying to a number of requests (ideally sending an SSL close notify, i.e. SSL_shutdown() as it does so), at which point the SSL connection is half-closed.  With a full-duplex protocol, you may also need to handle reading outstanding replies on a connection that no longer supports writes.

--
        Viktor.