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@xxxxxxxxxxx] On Behalf > Of Matt Caswell > Sent: Friday, September 07, 2018 11:24 AM > To: openssl-users@xxxxxxxxxxx > Subject: Re: 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.jahn@xxxxxxxx> >> 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
