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
