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