subject:"Re\: \[openssl\-users\] SSL_connect returns SSL_ERROR

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

2018-09-10 Thread 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-boun...@openssl.org] On Behalf
> Of Matt Caswell
> Sent: Friday, September 07, 2018 11:24 AM
> To: openssl-users@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:

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

2018-09-10 Thread 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 [mailto:openssl-users-boun...@openssl.org] On Behalf Of 
Matt Caswell
Sent: Friday, September 07, 2018 11:24 AM
To: openssl-users@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@atos.net_ <mailto:gerhard.j...@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

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

2018-09-08 Thread Matt Caswell




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_ 
> 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

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

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

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

3 matches

Site Navigation

Mail list logo

Footer information