DTLS handshake restarted by ClientHello using invalid message sequence numbers
Update
Check the comment below. The behavior appears to be grounded in the RFC. If that's the case and the behavior is intended/not unexpected, I think the issue can be closed.
Description of problem:
GnuTLS does not appear to validate message sequence numbers in ClientHello messages. According to DTLS RFC:
The first message each side transmits in each handshake always has message_seq = 0. Whenever each new message is generated, the message_seq value is incremented by one.
We found that GnuTLS does not check for message_seq to be 0 in a ClientHello delivered in the middle of an on-going handshake.
Version of gnutls used:
3.7.1
Operating System
Ubuntu 20
How reproducible:
I attached files necessary for reproduction (see reproduction.tar.gz) using DTLS-Fuzzer. Also included in the archive is a capture of the interaction similar to the one described. 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-serv utility (it is assumed the correct version of GnuTLS is already installed)
- launch DTLS-Fuzzer to execute input sequence found in 'test_sequence', upon which DTLS-Fuzzer will send the client messages shown the capture below.
Actual results:
If everything works as planned, Wireshark should show an interaction similar to that in the image below:
Therein, if we check the value of the highlighted restarting ClientHello message, we see:
Expected results:
The server should not have restarted the handshake using this message.
Thanks! reproduction.tar.gz