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