no suitable signature algorithm during handshake failure

[Quanah Gibson-Mount]

--On Friday, January 8, 2021 4:44 PM -0500 Viktor Dukhovni 
<openssl-users at dukhovni.org> wrote:

Hi Viktor,

> On Fri, Jan 08, 2021 at 12:05:26PM -0800, Quanah Gibson-Mount wrote:
>
>> >     https://www.spinics.net/lists/openssl-users/msg05623.html
>>
>> Thanks Viktor.  Mainly, I wasn't sure what specific information would be
>> necessary.  Here's what wireshark shows (IP addresses obfuscated):
>
> It would be really helpful (also to you) if you install a more
> up-to-date version of tshark, or copy the pcap file to a machine
> that already has one.  The version used below fails to understand
> many relevant modern TLS extensions/features.

I've relayed this to our client. ;)

>> ! --->      Extension: Unknown 43         -- i.e. supported_versions!
>>                 Type: Unknown (0x002b)    -- Almost certainly w/ TLS 1.3
>>                 Length: 9
>>                 Data (9 bytes)
>> ! --->      Extension: Unknown 45         -- psk_key_exchange_modes
>>                 Type: Unknown (0x002d)    -- a TLS 1.3 feature
>>                 Length: 2
>>                 Data (2 bytes)
>> ! --->      Extension: Unknown 51         -- key_share
>>                 Type: Unknown (0x0033)    -- a TLS 1.3 feature


I ran their pcap through my own updated version of tshark, and indeed:

            Extension: status_request_v2 (len=9)
                Type: status_request_v2 (17)
                Length: 9
                Certificate Status List Length: 7
                Certificate Status Type: OCSP Multi (2)
                Certificate Status Length: 4
                Responder ID list Length: 0
                Request Extensions Length: 0
            Extension: extended_master_secret (len=0)
                Type: extended_master_secret (23)
                Length: 0
            Extension: supported_versions (len=9)
                Type: supported_versions (43)
                Length: 9
                Supported Versions length: 8
                Supported Version: TLS 1.3 (0x0304)
                Supported Version: TLS 1.2 (0x0303)
                Supported Version: TLS 1.1 (0x0302)
                Supported Version: TLS 1.0 (0x0301)
            Extension: psk_key_exchange_modes (len=2)
                Type: psk_key_exchange_modes (45)
                Length: 2
                PSK Key Exchange Modes Length: 1
                PSK Key Exchange Mode: PSK with (EC)DHE key establishment 
(psk_dhe_ke) (1)
            Extension: key_share (len=71)
                Type: key_share (51)
                Length: 71
                Key Share extension
                    Client Key Share Length: 69
                    Key Share Entry: Group: secp256r1, Key Exchange length: 
65
                        Group: secp256r1 (23)
                        Key Exchange Length: 65
                        Key Exchange: 
04524e56171cf3e75903228cf4cc02687df2698bd43d167f…


> None were PSS, and RFC 8446 says:
>
>    In addition, the signature algorithm MUST be compatible with the key
>    in the sender's end-entity certificate.  RSA signatures MUST use an
>    RSASSA-PSS algorithm, regardless of whether RSASSA-PKCS1-v1_5
>    algorithms appear in "signature_algorithms".  The SHA-1 algorithm
>    MUST NOT be used in any signatures of CertificateVerify messages.
>
>> > What sort of certificate does the server have.  Are there any ssl
>> > module settings in its openssl.cnf file?

> The certificate does not require PSS, but TLS 1.3 does.

Great, thanks so much for the help! I learned some along the way, which is 
always a good thing. :)

Regards,
Quanah


--

Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>