SSL_connect returns SSL_ERROR_SYSCALL and errno == EWOULDBLOCK

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

SSL_connect returns SSL_ERROR_SYSCALL and errno == EWOULDBLOCK

Jahn, Gerhard
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_SYSCALL and 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…
 
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
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 Inhalte der 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
Reply | Threaded
Open this post in threaded view
|

Re: SSL_connect returns SSL_ERROR_SYSCALL and errno == EWOULDBLOCK

Matt Caswell-2


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@atos.net_ <mailto:[hidden email]>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: SSL_connect returns SSL_ERROR_SYSCALL and errno == EWOULDBLOCK

Jahn, Gerhard
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.
 
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 [[hidden email]] On Behalf Of Matt Caswell
Sent: Friday, September 07, 2018 11:24 AM
To: [hidden email]
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@atos.net_ <[hidden email]>
> 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
 

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: SSL_connect returns SSL_ERROR_SYSCALL and errno == EWOULDBLOCK

Matt Caswell-2


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:[hidden email]] On Behalf
> Of Matt Caswell
> Sent: Friday, September 07, 2018 11:24 AM
> To: [hidden email]
> 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@atos.net_ <mailto:[hidden email]>
>> 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
>  
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users