<div dir="ltr"><div>Hi Matt,</div><div><br></div><div>Thanks for the detailed response. </div><div>As you suggested there is definitely a lot to improve in our code to convey the correct meaning of the code. I have tested with the changes and it conveyed the correct meaning now as you clearly stated. </div><div><br></div><div>I just have one more doubt. Now I tried to test with the code with an ongoing customer scenario where we do not get any error or error string or the libssl method name as well. Mostly it happens when SSL_get_error() after SSL_do_handshake() returns <a name="line1144" style="color:rgb(0,0,0)">SSL_ERROR_SYSCALL. </a></div><div><a name="line1144" style="color:rgb(0,0,0)"><br></a></div><div><a name="line1144" style="color:rgb(0,0,0)">Is there any way to capture more information about this error ? </a></div><div><a name="line1144" style="color:rgb(0,0,0)"><br></a></div><div><a name="line1144" style="color:rgb(0,0,0)">Thanks a lot again for your timely response. </a></div><div><a name="line1144" style="color:rgb(0,0,0)"><br></a></div><div><a name="line1144" style="color:rgb(0,0,0)">Regards,</a></div><div><a name="line1144" style="color:rgb(0,0,0)">Ram Krushna</a></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 4, 2019 at 3:34 AM <<a href="mailto:openssl-users-request@openssl.org">openssl-users-request@openssl.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send openssl-users mailing list submissions to<br>
<a href="mailto:openssl-users@openssl.org" target="_blank">openssl-users@openssl.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:openssl-users-request@openssl.org" target="_blank">openssl-users-request@openssl.org</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:openssl-users-owner@openssl.org" target="_blank">openssl-users-owner@openssl.org</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of openssl-users digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11<br>
EAGAIN (John Unsworth)<br>
2. Reg Change in Error Code (ramakrushna mishra)<br>
3. Re: Reg Change in Error Code (Matt Caswell)<br>
4. Re: Any timeframe for the 1.1.1c release? (Viktor Dukhovni)<br>
5. Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11<br>
EAGAIN (Viktor Dukhovni)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 3 May 2019 09:34:14 +0000<br>
From: John Unsworth <<a href="mailto:John.Unsworth@synchronoss.com" target="_blank">John.Unsworth@synchronoss.com</a>><br>
To: "<a href="mailto:openssl-users@openssl.org" target="_blank">openssl-users@openssl.org</a>" <<a href="mailto:openssl-users@openssl.org" target="_blank">openssl-users@openssl.org</a>><br>
Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11<br>
EAGAIN<br>
Message-ID:<br>
<<a href="mailto:DM6PR07MB4650AF92014D45DBB2017095F5350@DM6PR07MB4650.namprd07.prod.outlook.com" target="_blank">DM6PR07MB4650AF92014D45DBB2017095F5350@DM6PR07MB4650.namprd07.prod.outlook.com</a>><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Testing changed code.<br>
<br>
Regards<br>
John<br>
<br>
________________________________<br>
From: openssl-users <<a href="mailto:openssl-users-bounces@openssl.org" target="_blank">openssl-users-bounces@openssl.org</a>> on behalf of Matt Caswell <<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>><br>
Sent: Friday, May 3, 2019 10:16 am<br>
To: <a href="mailto:openssl-users@openssl.org" target="_blank">openssl-users@openssl.org</a><br>
Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11 EAGAIN<br>
<br>
CAUTION: This email originated from outside of Synchronoss.<br>
<br>
<br>
On 02/05/2019 18:23, Viktor Dukhovni wrote:<br>
>>> At this point you'd be calling SSL_get_error(), is there a lock that<br>
>>> prevents writes between SSL_read() and SSL_read() and SSL_get_error()?<br>
>><br>
>> The mutex does not protect SSL_get_error() calls.<br>
><br>
> I think that's an application bug. The SSL_get_error() is using<br>
> the same SSL handle as the SSL_read(), which can be materially<br>
> altered by concurrent writes. (Matt, if you're still reading this<br>
> thread, do you agree?)<br>
><br>
> I would not release the mutex until after the call to SSL_get_error().<br>
<br>
An SSL object should not be used in multiple threads at the same time no matter<br>
what the API call. This applies to SSL_get_error() as well. If you are doing<br>
that then that could most definitely cause the behaviour you are seeing.<br>
<br>
Matt<br>
<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mta.openssl.org/pipermail/openssl-users/attachments/20190503/7209280b/attachment-0001.html" rel="noreferrer" target="_blank">http://mta.openssl.org/pipermail/openssl-users/attachments/20190503/7209280b/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 3 May 2019 20:48:05 +0530<br>
From: ramakrushna mishra <<a href="mailto:rama.krushna7@gmail.com" target="_blank">rama.krushna7@gmail.com</a>><br>
To: <a href="mailto:openssl-users@openssl.org" target="_blank">openssl-users@openssl.org</a><br>
Subject: Reg Change in Error Code<br>
Message-ID:<br>
<CAHgr=<a href="mailto:kKorZgv4ezpaT6nxtioqJPvyS-w2rVRvA7YC0CBT5gk6Q@mail.gmail.com" target="_blank">kKorZgv4ezpaT6nxtioqJPvyS-w2rVRvA7YC0CBT5gk6Q@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Hi,<br>
<br>
When client(openssl) is configured with TLSv1 and Server(java) was<br>
configured with TLSv1_2, then in openssl version 1.1.0e we used to get the<br>
error code : 337002677( 0x141640B5). But with openssl 1.1.1 upgrade the<br>
error code changed to 337285301<br>
(0x141A90B5). Moreover Earlier in java also we used to see<br>
"javax.net.ssl.SSLHandshakeException: Caused by: Remote host closed<br>
connection during handshake " exception at the server end which is not seen<br>
now.<br>
<br>
Following are my doubts.<br>
<br>
1) Has anyone noticed this change ?<br>
2) Where these error codes ( 337002677) and (337285301) defined ?<br>
3) Why the java server will not throw the exception any more ?<br>
<br>
Any help is highly appreciated.<br>
<br>
Thanks and Regards,<br>
Ram Krushna<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://mta.openssl.org/pipermail/openssl-users/attachments/20190503/3368e8cb/attachment-0001.html" rel="noreferrer" target="_blank">http://mta.openssl.org/pipermail/openssl-users/attachments/20190503/3368e8cb/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Fri, 3 May 2019 16:46:23 +0100<br>
From: Matt Caswell <<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>><br>
To: <a href="mailto:openssl-users@openssl.org" target="_blank">openssl-users@openssl.org</a><br>
Subject: Re: Reg Change in Error Code<br>
Message-ID: <<a href="mailto:d1a9743c-3ea4-9445-02d6-8e7512e490fe@openssl.org" target="_blank">d1a9743c-3ea4-9445-02d6-8e7512e490fe@openssl.org</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
<br>
<br>
On 03/05/2019 16:18, ramakrushna mishra wrote:<br>
> Hi,<br>
> <br>
> When client(openssl) is configured with TLSv1 and Server(java) was configured<br>
> with TLSv1_2, then in openssl version 1.1.0e we used to get the error code<br>
> :?337002677( 0x141640B5). But with openssl 1.1.1 upgrade the error code changed<br>
> to 337285301<br>
> (0x141A90B5). Moreover Earlier in java also we used to see<br>
> "javax.net.ssl.SSLHandshakeException: Caused by: Remote host closed connection<br>
> during handshake " exception at the server end which is not seen now.?<br>
> <br>
> Following are my doubts.?<br>
> <br>
> 1) Has anyone noticed this change ??<br>
> 2) Where these error codes ( 337002677) and (337285301) defined ?<br>
<br>
You can use the command line "errstr" utility for the relevant openssl version<br>
to check their meanings. For 1.1.0e:<br>
<br>
$ openssl errstr 141640B5<br>
error:141640B5:SSL routines:tls_construct_client_hello:no ciphers available<br>
<br>
For 1.1.1:<br>
$ openssl errstr 141A90B5<br>
error:141A90B5:SSL routines:ssl_cipher_list_to_bytes:no ciphers available<br>
<br>
You can also get your application to generate these human readable error strings<br>
using the appropriate functions:<br>
<br>
<a href="https://www.openssl.org/docs/man1.1.1/man3/ERR_error_string.html" rel="noreferrer" target="_blank">https://www.openssl.org/docs/man1.1.1/man3/ERR_error_string.html</a><br>
<br>
Error codes are highly version specific and may change from one version to<br>
another. We do not provide any guarantee that the same error will always produce<br>
the same error code - so you should not rely on them remaining static. The<br>
different components of the error string tell you different things about the<br>
cause of the error. "SSL routines" tells us that the error came from libssl.<br>
"tls_construct_client_hello" tells us the name of the function in the source<br>
code that generated the error. Finally "no ciphers available" tells us<br>
specifically what the error was.<br>
<br>
In this case "no ciphers available" means that there are no configured<br>
ciphersuites that are suitable for use in your configuration. For example if<br>
your client is configured to only use TLSv1 but you've only configured<br>
ciphersuites suitable for use in TLSv1.2 then you will get this error.<br>
(Incidentally it seems very strange to use 1.1.0/1.1.1 but then restrict the<br>
client to using TLSv1 only - I'd recommend using the highest protocol version<br>
available for the library in use)<br>
<br>
This error occurs in the "tls_construct_client_hello" function (in 1.1.0e) which<br>
is very early in the handshake process. It occurs during construction of the<br>
very first message sent by the client (the ClientHello).<br>
<br>
It appears that in 1.1.1 the function that does this check has changed. It is<br>
now done in "ssl_cipher_list_to_bytes". This function is called from<br>
"tls_construct_client_hello". This is why the error code has changed - but it is<br>
the same underlying cause.<br>
?<br>
> 3) Why the java server will not throw the exception any more ? <br>
<br>
Looking at the code it appears that in 1.1.0e the client just abandons the<br>
connection attempt without sending any error alert to the server. In 1.1.1 it<br>
now sends an "internal_error" alert first. This is most likely the cause of the<br>
change of behaviour on the server side.<br>
<br>
Matt<br>
<br>
<br>
<br>
> ?<br>
> Any help is highly appreciated.?<br>
> <br>
> Thanks and?Regards,<br>
> Ram Krushna<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Fri, 3 May 2019 11:58:56 -0400<br>
From: Viktor Dukhovni <<a href="mailto:openssl-users@dukhovni.org" target="_blank">openssl-users@dukhovni.org</a>><br>
To: "<a href="mailto:openssl-users@openssl.org" target="_blank">openssl-users@openssl.org</a>" <<a href="mailto:openssl-users@openssl.org" target="_blank">openssl-users@openssl.org</a>><br>
Subject: Re: Any timeframe for the 1.1.1c release?<br>
Message-ID: <<a href="mailto:3BECA507-6AE2-40CA-981A-C08400767957@dukhovni.org" target="_blank">3BECA507-6AE2-40CA-981A-C08400767957@dukhovni.org</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
> On May 2, 2019, at 12:09 PM, Matt Caswell <<a href="mailto:matt@openssl.org" target="_blank">matt@openssl.org</a>> wrote:<br>
> <br>
>> when is the 1.1.1c expected to be released? There were plenty of bug<br>
>> fixes committed to the 1.1.1 branch since the 1.1.1b release. Is the<br>
>> 1.1.1c release imminent?<br>
> <br>
> There are no plans at the moment.<br>
<br>
There should perhaps be a 1.1.1c soonish... There are indeed many useful<br>
improvements committed, but not yet released.<br>
<br>
-- <br>
Viktor.<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Fri, 3 May 2019 18:04:05 -0400<br>
From: Viktor Dukhovni <<a href="mailto:openssl-users@dukhovni.org" target="_blank">openssl-users@dukhovni.org</a>><br>
To: <a href="mailto:openssl-users@openssl.org" target="_blank">openssl-users@openssl.org</a><br>
Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11<br>
EAGAIN<br>
Message-ID: <<a href="mailto:20190503220405.GF67454@straasha.imrryr.org" target="_blank">20190503220405.GF67454@straasha.imrryr.org</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Fri, May 03, 2019 at 09:34:14AM +0000, John Unsworth wrote:<br>
<br>
> Testing changed code.<br>
<br>
For the record, though I think you realise this, *both* the SSL_read()<br>
or SSL_write() and the following SSL_get_error() need to be protected<br>
as a unit by the *same* instance of the locked mutex. It would not<br>
be enough to lock these separately.<br>
<br>
acquire_lock();<br>
if (reading)<br>
ret = SSL_read(ssl, ...); <br>
else<br>
ret = SSL_write(ssl, ...);<br>
if (ret <= 0)<br>
err = SSL_get_error(ssl, ret);<br>
release_lock();<br>
<br>
/* Handle EOF and errors */<br>
<br>
-- <br>
Viktor.<br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
openssl-users mailing list<br>
<a href="mailto:openssl-users@openssl.org" target="_blank">openssl-users@openssl.org</a><br>
<a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
<br>
<br>
------------------------------<br>
<br>
End of openssl-users Digest, Vol 54, Issue 4<br>
********************************************<br>
</blockquote></div></div>