Reg Change in Error Code

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Reg Change in Error Code

ramakrushna mishra
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
Reply | Threaded
Open this post in threaded view
|

Re: Reg Change in Error Code

Matt Caswell-2


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
Reply | Threaded
Open this post in threaded view
|

Re: Reg Change in Error Code

ramakrushna mishra
In reply to this post by ramakrushna mishra
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 <[hidden email]> wrote:
Send openssl-users mailing list submissions to
        [hidden email]

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
        [hidden email]

You can reach the person managing the list at
        [hidden email]

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 <[hidden email]>
To: "[hidden email]" <[hidden email]>
Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11
        EAGAIN
Message-ID:
        <[hidden email]>

Content-Type: text/plain; charset="us-ascii"

Testing changed code.

Regards
John

________________________________
From: openssl-users <[hidden email]> on behalf of Matt Caswell <[hidden email]>
Sent: Friday, May 3, 2019 10:16 am
To: [hidden email]
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 <[hidden email]>
To: [hidden email]
Subject: Reg Change in Error Code
Message-ID:
        <CAHgr=[hidden email]>
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 <[hidden email]>
To: [hidden email]
Subject: Re: Reg Change in Error Code
Message-ID: <[hidden email]>
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 <[hidden email]>
To: "[hidden email]" <[hidden email]>
Subject: Re: Any timeframe for the 1.1.1c release?
Message-ID: <[hidden email]>
Content-Type: text/plain;       charset=us-ascii

> On May 2, 2019, at 12:09 PM, Matt Caswell <[hidden email]> 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 <[hidden email]>
To: [hidden email]
Subject: Re: SSL_read() returning SSL_ERROR_SYSCALL with errno 11
        EAGAIN
Message-ID: <[hidden email]>
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
[hidden email]
https://mta.openssl.org/mailman/listinfo/openssl-users


------------------------------

End of openssl-users Digest, Vol 54, Issue 4
********************************************
Reply | Threaded
Open this post in threaded view
|

Re: Reg Change in Error Code

Matt Caswell-2


On 04/05/2019 04:54, ramakrushna mishra wrote:

> 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. 
>
> Is there any way to capture more information about this error ?

The man pages have this description for SSL_ERROR_SYSCALL:

 SSL_ERROR_SYSCALL
 Some non-recoverable, fatal 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. If this error occurs then no further I/O operations should
 be performed on the connection and SSL_shutdown() must not be called.

 This value can also be returned for other errors, check the error queue for
 details.

So I'd suggest you check errno in such a scenario.

Matt