[openssl-users] SSL_connect returns SSL_ERROR_SYSCALL and errno == EWOULDBLOCK

[Matt Caswell]

On 10/09/18 09:05, Jahn, Gerhard wrote:
> Ad:  The "correct" answer is that if you get SSL_ERROR_SYSCALL then the
> connection has failed and you shouldn't use that connection any more.
>  
> This somehow contradicts the description of returncode <0 on SSL_connect
> which says that
>  
> <0
>  
>     The TLS/SSL handshake was not successful, because a fatal error
> occurred either at the protocol level or a connection failure occurred.
> The shutdown was not clean. It can also occur of *_action is need to
> continue the operation for non-blocking BIOs_*.
> Call SSL_get_error() with the return value ret to find out the reason.

I don't see any contradiction in the OpenSSL docs. All this says is that
if you get <=0 return code then you need to call SSL_get_error() to find
out what to do. If you get SSL_ERROR_SYSCALL then a *non-recoverable*
I/O error has occurred.

So, in my mind, the OpenSSL documentation is clear - you've got a
non-recoverable error and therefore you shouldn't continue.

If there is a contradiction it is between the OpenSSL docs which tell
you you have a non-recoverable error and the value of errno - which
suggests a recoverable error.

This is probably down to one of two things:

1) Something has caused the value of errno to change between when the
non-recoverable error occurred and when you're checking it

or

2) A bug in OpenSSL is incorrectly interpreting a recoverable error as a
non-recoverable one.

Matt


>  
> If SSL_ERROR_SYSCAL would always mean connection failure, why then any
> action to continue the operation…..
> So we’re getting SSL_connect() = -1 and we call SSL_get_error()
> returning 5  as advised
> Then as SSL_get_error() says
>  
> SSL_ERROR_SYSCALL
> Some non-recoverable I/O error occurred. The OpenSSL error queue may
> contain more information on the error.
> For socket I/O on Unix systems, consult *errno* for details
> We call  ERR_print_errors_fp(stderr)which gives no output.
> We inspect errno which indicates EWOULDBLOCK or EAGAIN
> This seems to happen rarely (once per hundreds of SSL_Connect) and as
> we’re currently treating any SSL_ERROR_SYSCALL
> as bogus and terminate the connection (SSL_shutdown+Socketclose)
> As our server runs “forever” and has high load we see a lot of such
> “SSL_Connect errors in our Logs”
> Additionally it seems to happen more frequently when connecting to a
> remote host rather than when connecting to a server co-located….
> I have experienced the same behavior with SSL_read/SSL_write where we
> also get SSL_ERROR_SYSCALL and find that errno is EWOULDBLOCK
> But in these cases we “know” what to do (wait for readable when it
> appears in SSL_read and wait for writeable when in SSL_write)
> Therefore we have the feeling that same blocking happens during
> SSL_connect……..?
> GJ
>  
> -----Original Message-----
> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf
> Of Matt Caswell
> Sent: Friday, September 07, 2018 11:24 AM
> To: openssl-users at openssl.org
> Subject: Re: [openssl-users] SSL_connect returns SSL_ERROR_SYSCALL and
> errno == EWOULDBLOCK
>  
>  
>  
> On 07/09/18 09:16, Jahn, Gerhard wrote:
>> Hi,
>>  
>> We are using OpenSSl 1.0.2n in our server running on LINUX.
>> We call SSL_connect() on async socket (after TCP connect completion) 
>> to establish a secure connection.
>> According to DOC SSL_get_error(() has to be called if SSL_connect() 
>> returns <=0
>>  
>> We do not understand what to do if SSL_get_error(() returns 
>> SSL_ERROR_SYSCALLand errno is EWOULDBLOCK If SSL_get_error returns 
>> SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE it pretty clear what to 
>> do… (we set the socket descriptor either in the readfds or writefds 
>> and call select to wait until the socket becomes readable or writeable 
>> (or times-out) But when EWOULDBLOCK is indicated, we do not know 
>> whether to wait for readable/writeable…… (setting both might be an 
>> idea but could easily lead to a live-loop as we suppose that the 
>> handshake either waits for a read or for a write but not both…
>  
> That's quite a surprising result. Possibly intervening code somewhere
> between the sys call and where you check errno has changed its value?
>  
> The "correct" answer is that if you get SSL_ERROR_SYSCALL then the
> connection has failed and you shouldn't use that connection any more.
> Have you checked the openssl error stack for any reported issues?
>  
> Matt
>  
>  
>  
>>  
>> Any ideas?
>> Thanks
>>  
>> Mit freundlichen Grüßen/Best regards,
>> *____________
>> **Gerhard Jahn*
>> 
>> Identity and Access Management
>>  
>> Phone:  +49 (211) 399-33276
>> Phone:  +49 (211) 399-22891
>> Email: _gerhard.jahn at atos.net_ <mailto:gerhard.jahn at atos.net>
>> Otto-Hahn-Ring 6
>> 81739 München, Germany
>> de.atos.net
>> 
>> Atos Information Technology GmbH; Geschäftsführung: Winfried Holz, Udo 
>> Littke; Vorsitzender des Aufsichtsrats: N.N.; Sitz der Gesellschaft:
>> München; Registergericht: München, HRB 235509.
>> 
>> Diese E-Mail und etwaige Anlagen enthalten firmenvertrauliche 
>> Informationen, die ausschließlich für den Empfänger bestimmt sind.
>> Sollten Sie diese E-Mail irrtümlich erhalten haben, benachrichtigen 
>> Sie bitte unverzüglich den Absender per Antwort-Mail und löschen Sie 
>> diese E-Mail nebst Anlagen von Ihrem System. Da die Integrität 
>> innerhalb des Internets nicht zu gewährleisten ist, kann die Atos 
>> Gruppe für die Inhalteder Nachricht kein Haftung übernehmen. Obwohl 
>> der Absender anstrebt ein virusfreies Computernetzwerk 
>> sicherzustellen, kann der Absender nicht gewährleisten, dass diese 
>> E-Mail virusfrei ist und wird damit keine Haftung bei Schäden auf 
>> Grund einer Virusübermittlung übernehmen.
>> 
>> This e-mail and the documents attached are confidential and intended 
>> solely for the addressee; it may also be privileged. If you receive 
>> this e-mail in error, please notify the sender immediately and destroy 
>> it. As its integrity cannot be secured on the Internet, the Atos group 
>> liability cannot be triggered for the message content. Although the 
>> sender endeavors to maintain a computer virus-free network, the sender 
>> does not warrant that this transmission is virus-free and will not be 
>> liable for any damages resulting from any virus transmitted.
>>  
>>  
>>  
>>  
>> 
>> 
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>  
> 
>