Differences in defaults between 1.0.2 and 1.1.1

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

Differences in defaults between 1.0.2 and 1.1.1

gperrow

I have an LDAP server that accepts TLS connections, and I can make a connection to it using “openssl s_client -showcerts -host <host>:<port> -debug”. The output shows this is a TLSv1.2 connection using ECDHE-RSA-AES128-SHA. This is using OpenSSL version 1.0.2j.

 

If I run exactly the same command using the openssl executable built with 1.1.1, I get errors:

 

CONNECTED(00000184)

write to 0x2917b30 [0x2928090] (326 bytes => 326 (0x146))

0000 - 16 03 01 01 41 01 00 01-3d 03 03 5a e6 ad 03 79   ....A...=..Z...y

...

0140 - cb bb 7f 9c 78 24                                 ....x$

read from 0x2917b30 [0x291edf3] (5 bytes => 0 (0x0))

write:errno=0

---

no peer certificate available

---

No client certificate CA names sent

---

SSL handshake has read 0 bytes and written 326 bytes

Verification: OK

---

New, (NONE), Cipher is (NONE)

Secure Renegotiation IS NOT supported

Compression: NONE

Expansion: NONE

No ALPN negotiated

Early data was not sent

Verify return code: 0 (ok)

---

read from 0x2917b30 [0x290e960] (8192 bytes => 0 (0x0))

 

The connection is closed by the server, which is reporting an error:

 

TLS: error: accept - force handshake failure: errno 11 - moznss error -12162

TLS: can't accept: TLS error -12162:Unsupported hash algorithm used by TLS peer..

 

If I add the -no_tls1_2 switch, the openssl 1.1.1 command succeeds. Since the server didn’t change and the client command line didn’t change, it would seem that some default behaviour has changed within OpenSSL for 1.1.1. I know that some ciphersuites were removed or disabled but the one used by OpenSSL 1.0.2j (ECDHE-RSA-AES128-SHA) does not seem to be one of them (it’s listed in “openssl ciphers”). Does anyone know what might be happening here?

Thanks

Graeme Perrow

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Differences in defaults between 1.0.2 and 1.1.1

Hubert Kario
On Tuesday, 19 March 2019 14:40:19 CET Perrow, Graeme wrote:

> I have an LDAP server that accepts TLS connections, and I can make a
> connection to it using "openssl s_client -showcerts -host <host>:<port>
> -debug". The output shows this is a TLSv1.2 connection using
> ECDHE-RSA-AES128-SHA. This is using OpenSSL version 1.0.2j.
>
> If I run exactly the same command using the openssl executable built with
> 1.1.1, I get errors:
>
> CONNECTED(00000184)
> write to 0x2917b30 [0x2928090] (326 bytes => 326 (0x146))
> 0000 - 16 03 01 01 41 01 00 01-3d 03 03 5a e6 ad 03 79   ....A...=..Z...y
> ...
> 0140 - cb bb 7f 9c 78 24                                 ....x$
> read from 0x2917b30 [0x291edf3] (5 bytes => 0 (0x0))
> write:errno=0
> ---
> no peer certificate available
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 0 bytes and written 326 bytes
> Verification: OK
> ---
> New, (NONE), Cipher is (NONE)
> Secure Renegotiation IS NOT supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> Early data was not sent
> Verify return code: 0 (ok)
> ---
> read from 0x2917b30 [0x290e960] (8192 bytes => 0 (0x0))
>
> The connection is closed by the server, which is reporting an error:
>
> TLS: error: accept - force handshake failure: errno 11 - moznss error -12162
> TLS: can't accept: TLS error -12162:Unsupported hash algorithm used by TLS
> peer..
>
> If I add the -no_tls1_2 switch, the openssl 1.1.1 command succeeds. Since
> the server didn't change and the client command line didn't change, it
> would seem that some default behaviour has changed within OpenSSL for
> 1.1.1. I know that some ciphersuites were removed or disabled but the one
> used by OpenSSL 1.0.2j (ECDHE-RSA-AES128-SHA) does not seem to be one of
> them (it's listed in "openssl ciphers"). Does anyone know what might be
> happening here? Thanks
the error would indicate that the server is using Mozilla NSS library for the
TLS implementation.

I recall that some very old NSS versions were intolerant to undefined
signature algorithms[1,2]. Which NSS version is the server using?

And OpenSSL needs to add rsa_pss_* signature algorithms to the ClientHello -
those are the only ones allowed for RSA keys in TLS 1.3 - the bug is in the
server.

 1 - https://bugzilla.mozilla.org/show_bug.cgi?id=1119983
 2 - https://bugzilla.mozilla.org/show_bug.cgi?id=1317857
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky┼łova 115, 612 00  Brno, Czech Republic

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Differences in defaults between 1.0.2 and 1.1.1

Matt Caswell-2
In reply to this post by gperrow


On 19/03/2019 13:40, Perrow, Graeme wrote:
> TLS: error: accept - force handshake failure: errno 11 - moznss error -12162
>
> TLS: can't accept: TLS error -12162:Unsupported hash algorithm used by TLS peer..


Just to confirm - you've not configured client authentication?

Assuming not, the above error message from the server suggests that it doesn't
like one of the signature algorithms sent through from the client in the
ClientHello. At least I'm assuming that's the point at which it fails. You
omitted most of the -debug output so its a little unclear exactly how far
through the handshake it got before the failure occurred. If my assumption is
right then it looks like the server may be behaving incorrectly. It isn't
supposed to fail if it encounters a parameter it doesn't recognise - its just
supposed to ignore it.

To test the theory I suggest sending through the same list of signature
algorithms in the same order that 1.0.2 sends them. You can do that using the
"-sigalgs" parameter to s_client:

openssl s_client -showcerts -host <host>:<port> -debug -sigalgs
"RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1"

Matt
Reply | Threaded
Open this post in threaded view
|

RE: Differences in defaults between 1.0.2 and 1.1.1

gperrow
Thanks Matt, the command you listed did succeed. I was hoping to be able to change our code so that we could connect to any server we were able to connect to before, but if this is truly a server-side bug, there's only so much we can do on the client side.

If our customers see this change in behaviour after we upgrade OpenSSL, my understanding is that they will simply have to fix their server.

Graeme

-----Original Message-----
From: openssl-users <[hidden email]> On Behalf Of Matt Caswell
Sent: March 19, 2019 10:23 AM
To: [hidden email]
Subject: Re: Differences in defaults between 1.0.2 and 1.1.1



On 19/03/2019 13:40, Perrow, Graeme wrote:
> TLS: error: accept - force handshake failure: errno 11 - moznss error -12162
>
> TLS: can't accept: TLS error -12162:Unsupported hash algorithm used by TLS peer..


Just to confirm - you've not configured client authentication?

Assuming not, the above error message from the server suggests that it doesn't
like one of the signature algorithms sent through from the client in the
ClientHello. At least I'm assuming that's the point at which it fails. You
omitted most of the -debug output so its a little unclear exactly how far
through the handshake it got before the failure occurred. If my assumption is
right then it looks like the server may be behaving incorrectly. It isn't
supposed to fail if it encounters a parameter it doesn't recognise - its just
supposed to ignore it.

To test the theory I suggest sending through the same list of signature
algorithms in the same order that 1.0.2 sends them. You can do that using the
"-sigalgs" parameter to s_client:

openssl s_client -showcerts -host <host>:<port> -debug -sigalgs
"RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1"

Matt
Reply | Threaded
Open this post in threaded view
|

Re: Differences in defaults between 1.0.2 and 1.1.1

Matt Caswell-2


On 19/03/2019 15:15, Perrow, Graeme wrote:
> Thanks Matt, the command you listed did succeed. I was hoping to be able to
> change our code so that we could connect to any server we were able to
> connect to before, but if this is truly a server-side bug, there's only so
> much we can do on the client side.
>
> If our customers see this change in behaviour after we upgrade OpenSSL, my
> understanding is that they will simply have to fix their server.

Fixing the server really is the right solution here. It is broken and clients
shouldn't be forced to work around such broken set ups.

If you absolutely *had* to do it, you can do the same workaround in C code that
s_client does with that "-sigalgs" parameter using the function
SSL_CTX_set1_sigalgs (or SSL_set1_sigalgs):

https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set1_sigalgs.html

But I'd strongly advise against it since using such a sigalgs list will impact
your ability to interoperate with TLSv1.3 servers.

Matt


>
> Graeme
>
> -----Original Message----- From: openssl-users
> <[hidden email]> On Behalf Of Matt Caswell Sent: March 19,
> 2019 10:23 AM To: [hidden email] Subject: Re: Differences in
> defaults between 1.0.2 and 1.1.1
>
>
>
> On 19/03/2019 13:40, Perrow, Graeme wrote:
>> TLS: error: accept - force handshake failure: errno 11 - moznss error
>> -12162
>>
>> TLS: can't accept: TLS error -12162:Unsupported hash algorithm used by TLS
>> peer..
>
>
> Just to confirm - you've not configured client authentication?
>
> Assuming not, the above error message from the server suggests that it
> doesn't like one of the signature algorithms sent through from the client in
> the ClientHello. At least I'm assuming that's the point at which it fails.
> You omitted most of the -debug output so its a little unclear exactly how
> far through the handshake it got before the failure occurred. If my
> assumption is right then it looks like the server may be behaving
> incorrectly. It isn't supposed to fail if it encounters a parameter it
> doesn't recognise - its just supposed to ignore it.
>
> To test the theory I suggest sending through the same list of signature
> algorithms in the same order that 1.0.2 sends them. You can do that using
> the "-sigalgs" parameter to s_client:
>
> openssl s_client -showcerts -host <host>:<port> -debug -sigalgs
> "RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1"
>
>  Matt
>