8 Nov
2022
8 Nov
'22
4:10 p.m.
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
>
>