Hi Simon,

Thank you for reporting this. After digging down, it's a functional bug in Mbed TLS, which unfortunately is not easy to fix. It's now filed as https://github.com/Mbed-TLS/mbedtls/issues/6566 .

Sorry for taking a while to reply. For a moment we were worried there might be a security issue since using the wrong algorithm could lead to a policy violation, but no, it's just a non-compliance and interoperability problem.

Best regards,

--
Gilles Peskine
Mbed TLS developer

On 21/10/2022 19:52, Simon Nachtigall via mbed-tls wrote:

Hello everyone,

 

We observed a strange behavior in the mbedTLS client, when client authentication is requested by the TLS server. This behavior was observed in the newer version 3.0.0 as well as in older versions.

 

The scenario is the following: The server selects a ciphersuite e.g. ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and sends a CertificateRequest message that only includes the ecdsa_secp256r1_sha256 signature algorithm.

However, the mbedTLS client simply ignores the requested hash function and uses ecdsa_secp256r1_sha384 for the signature in the ClientVerify.

Then, the server complains since the signature does not match with the requested signature algorithm and sends a handshake failure.

It seems that mbedTLS does not store the requested signature algorithms/hash function from the CertificateRequest and always uses the hash function from the selected ciphersuite.

 

 

In the ssl_write_certificate_verify function, we find the following comment:

 

/*

         * digitally-signed struct {

         *     opaque handshake_messages[handshake_messages_length];

         * };

         *

         * Taking shortcut here. We assume that the server always allows the

         * PRF Hash function and has sent it in the allowed signature

         * algorithms list received in the Certificate Request message.

         *

         * Until we encounter a server that does not, we will take this

         * shortcut.

         *

         * Reason: Otherwise we should have running hashes for SHA512 and

         *         SHA224 in order to satisfy 'weird' needs from the server

         *         side.

         */

 

 

Is this a known problem and is there any fix available?

 

Cheers,

 

Simon Nachtigall