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.
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
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
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 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….
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……..?
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
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
