Client responds to CertificateRequest incorrectly, potentially causing interoperability problems

[pfg666]

Your environment.

• Version: 2.0.9
• Browser: N/A
• Other Information - OS: Ubuntu 20

What did you do?

Test how the PionDTLS client behaves when asked to authenticate with a certificate of a type it does not own.
The RFC mandates in this case that the client responds with an empty certificate as per:

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. That is, the certificate_list structure has a length of zero.

What did you expect?

An empty certificate from the client.

What happened?

The client responded with the certificate under its possession, despite it being of the wrong type. This is seen in the bellow capture taken on my machine. The capture is included in the reproduction files provided at the end.

Notice the CertificateRequest sent by the server. If we look at this records we see that the server asks for a Certificate of type RSA Sign (containing an RSA public key).

The client, whose certificate contains an EC public key, wrongly provides its certificate despite it being the wrong type (by not containing an RSA public key).

We found the problem to also affect MbedTLS clients and posted an issue. There we also explain how this can lead to interoperability problems between clients and servers who request but not require client certificates for handshake completion. The client providing a wrong certificate may cause the server to terminate the handshake, which would not happen if the client had provided an empty certificate.

Steps to Reproduce

I attached files necessary for reproduction on the server (see reproduction.tar.gz) using DTLS-Fuzzer and a PionDTLS client/server program we use for testing. Also included in the archive is the capture shown earlier. 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 PionDTLS and DTLS-Fuzzer;
• launch DTLS-Fuzzer in server mode in order to execute input sequence found in 'test_sequence' exposing this problem;
• launch the PionDTLS client.

Let me know if you can confirm this behavior.

Thanks.

reproduce.tar.gz

[daenney]

Thanks so much for raising this with us and all the detail provided in the bug report!

As an aside, I hadn't seen DTLS fuzzer before, seems great. @Sean-Der @at-wat does either of you have an idea on how we could integrate that in CI? It feels like this could help us close the long-standing #4.

[pfg666]

DTLS-Fuzzer is a state fuzzer capable of automatically generating models for clients and servers. On analyzing the models, bugs such as this one can be found. The 'public' version currently only supports servers, whereas the development version (the one used here) also supports clients, and means of automatically detecting the bugs/generating input sequences that expose the invalid behavior. The development version is still in somewhat of a rough state, but we want to make a clean release at some point in the future.

DTLS-Fuzzer is based on TLS-Attacker, an actively maintained TLS/DTLS test library, which you also may consider for CI. TLS-Attacker has the advantage that it allows you to build test cases for most scenarios. Also, it is a robust library, already integrated in the CI of some TLS libraries (see Botan). DTLS-Fuzzer on the other hand, is restricted to only a small set of inputs (such as those in 'test_sequence') and is more of a research prototype. Its advantage is that in the planned release, it will allow you to detect control flow bugs such as this one automatically, without the need of any test cases.

I think both tools can serve in CI: DTLS-Fuzzer to ensure that no new control flow bugs spring up, TLS-Attacker to execute/maintain regression test cases for fixed bugs.

[Sean-Der]

I would love to do that @daenney! I am a few weeks out from having free time, but sounds like a great weekend project :)

Sounds like getting TLS-Attacker setup today in the best first step? I hadn't heard of these tools before, but I am sure we will find some good bugs/additional work :)