Question about handshake error

[Matt Caswell]

On 11/03/2020 08:56, Niki Dinsey wrote:
> openssl s_client -connect thankqcrm.accessacloud.com:443
> <http://thankqcrm.accessacloud.com:443>
> 
> * Debian 10 + 1.1.1d - Handshake Error  
> * Debian 9 + 1.1.0l - Working
> * Ubuntu 18.04 + 1.1.1  11 Sep 2018 -Working
> * Ubuntu 19.10 + 1.1.1c  28 May 2019 - Working
> * Ubuntu 20.04 + 1.1.1d - Handshake Error
> 
> The handshake errors can be bypassed using switch -tls1_1 on Debian 10
> 
> So I'm seeing a pattern here, as for what exactly I'm stumped! If
> anybody else can replicate using Debian 10 + 1.1.1d I'd appreciate it.
> But as for where to go from here I'm lost.

Hi Niki

I installed a Debian 10 VM and was able to reproduce this error.

AFAICT, this appears to be due to a combination of a server
mis-configuration, a slightly over-zealous server implementation
applying the standards, and a debian specific openssl patch.

I was able to isolate the difference between a successful handshake and
a failing handshake. This is in the "signature algorithms" (sigalgs)
extension of the ClientHello. This signals to the server what algorithms
the client is willing to accept for handshake and certificate signatures.

The important difference is that debian 10, by default, no longer seems
to include any sigalgs that are based on SHA1 due to security concerns
with that hash algorithm.

Looking at the certificate chain sent by the server it does indeed
include some certificates that are signed using SHA1. What is slightly
odd about the certificate chain sent be the server is that it includes
the root certificate - which is normally not sent (the client is
expected to have that certificate already in its trust store). It is
only the root certificate that is signed using SHA1. Even more strange
is that the server seems to be sending 2 copies of the root cert!

I *think* what is happening is the server is checking the chain it has
been configured with, spotting that it includes a SHA1 based signature
and therefore refusing to respond at all because the client has not
indicated SHA1 support. IIRC openssl is a little less strict in this
regards and would send the certificate anyway if it doesn't have a
better alternative.

I was able to get a successful connection from debian 10 using this
command line:

openssl s_client -connect thankqcrm.accessacloud.com:443 -sigalgs
"RSA+SHA256:RSA+SHA1" -cipher "DEFAULT:@SECLEVEL=0"

The full default sigalgs sent by a non-patched version of OpenSSL are:

ecdsa_secp256r1_sha256:ecdsa_secp384r1_sha384:ecdsa_secp521r1_sha512
:ed25519:ed448:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512
:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512
:rsa_pkcs1_sha256:rsa_pkcs1_sha384:rsa_pkcs1_sha512:ECDSA+SHA224
:ECDSA+SHA1:RSA+SHA224:RSA+SHA1:DSA+SHA224:DSA+SHA256:DSA+SHA384
:DSA+SHA512

Debian 10 omits all the SHA1 entries from the above list. Note that
Debian 10 will only allow SHA1 if the security level is explicitly set
to 0 (via the -cipher "DEFAULT:@SECLEVEL=0" command line arg). Probably
because the debian patch is the same as this one:

https://github.com/openssl/openssl/pull/10786

Which was also applied to the mainline 1.1.1 dev branch - but we already
decided to revert it here:

https://github.com/openssl/openssl/pull/11282


I would recommend that the server operator removes both copies of the
root cert from its cert chain. Hopefully this should then mean that it
does not see the SHA1 root and will therefore continue the handshake. If
you can't get the server operator to make this change then, as a
workaround, you'd have to change your application configuration to add
back in the missing sigalgs and switch the security level to 0.

Matt