[gnutls-devel] GnuTLS | DTLS client responds to CertificateRequest with Certificate of the wrong type (potential interop. problems) (#1245)

[Read-only notification of GnuTLS library development activities]

Paul created an issue: https://gitlab.com/gnutls/gnutls/-/issues/1245




## Version of gnutls used:
3.7.1

## Operating System
Ubuntu 20

## Description of problem:

The problem regards, as the title suggests, the client's Certificate response to a CertificateRequest by the server. The [TLS 1.2 RFC](https://datatracker.ietf.org/doc/html/rfc5246#page-54) introduces the following requirements on the client Certificate:

>   The end-entity certificate provided by the client MUST contain a key 
>   that is compatible with certificate_types.

>  This message is only sent if the server requests a certificate. If no 
>  suitable certificate is available, the client MUST send a certificate 
>  message containing no certificates.

According to our testing, the GnuTLS DTLS client responds with the Certificate under its possession even if it is unsuitable. In our case, unsuitable means that the type of the public key contained in the Certificate is not compatible with certificate_types in CertificateRequest. This is showcased in the below capture of an interaction with a GnuTLS client.

![gnutls_wrong_certificate_type](/uploads/22e0d763a3a8b08d2991f87ff10917bc/gnutls_wrong_certificate_type.png)

Inspection of the CertificateRequest and client Certificate messages reveals the incompatibility (DSS_SIGN requires a DSA key, whereas the client Certificate contains an RSA key).

![gnutls_wrong_certificate_type_certreq](/uploads/319b6c45d958d3bd8fb31dfdd089abf5/gnutls_wrong_certificate_type_certreq.png)

![gnutls_wrong_certificate_type_cert](/uploads/d73401e981fd101670a44a7afc16039e/gnutls_wrong_certificate_type_cert.png)

This behavior can lead to interoperability problems when connecting to servers that request but do not require client Certificates. On receiving a Certificate of the wrong type from the client, the server may abort the handshake, which would have been avoided had the client sent an empty Certificate message. A similar bug has been shown to affect MbedTLS. In the respective [issue](https://github.com/ARMmbed/mbedtls/issues/4059) we also give a concrete interoperability scenario involving an MbedTLS client and OpenSSL server where the two sides fail to complete the handshake because of this issue.

## How reproducible:
[Attached](/uploads/2b5d9f9ea12e2014e890bce23b27dccb/reproduction.tar.gz) are the files necessary for reproduction using [DTLS-Fuzzer](https://github.com/assist-project/dtls-fuzzer/). Also included in the archive is the capture shown above. DTLS-Fuzzer requires  the JDK for Java 8. On Ubuntu, this can be installed  by running:
`sudo apt-get install openjdk-8-jdk`

Unpack the archive, `cd` to resulting folder and run `bash reproduce.sh`, while running an instance of Wireshark on the side. The reproduction script will: 
* setup DTLS-Fuzzer;
* launch gnutls-cli utility (it is assumed the correct version of GnuTLS is already installed)
* launch DTLS-Fuzzer to execute input sequence found in 'test_sequence' to expose this problem. 

## Actual results:
The client generates a non-empty Certificate message whose public key is incompatible with the certificate_types in CertificateRequest.

## Expected results:
The client should have responded with an empty Certificate.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1245
You're receiving this email because of your account on gitlab.com.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20210525/5821e002/attachment.html>