DTLS handshake restarted with invalid message sequence numbers

[pfg666]

Update

Check the comment below as the message sequence numbers may be generated by conforming clients in rare scenarios. This relates to both this and issue 4031.

Description

• Type: Bug
• Priority: Minor

Non-conformance Bug

OS
Linux, Ubuntu 20

build:
Version: 4.7.1r

Affected Versions DTLS 1.2

Expected behavior According to the DTLS 1.2. 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.

This means the server should not re-start a handshake on processing a ClientHello whose message_seq is greater than 0.

Actual Behavior Our testing shows that the WolfSSL server does not properly validate the message_seq field. It responds to a mid-handshake ClientHello with an increased sequence number by generating a new ServerHello flight.

Steps to Reproduce I attached files necessary for reproduction (see reproduction.tar.gz) using TLS-Attacker, a Java-based tool for testing TLS libraries. Also included in the archive is a capture of the interaction, generated on my machine. TLS-Attacker 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 WolfSSL 4.7.1r and Tls-Attacker;
• launch an WolfSSL server
• launch TLS-Attacker, execute test.

If everything works as planned, Wireshark should show an interaction similar to that in the image below:

Notice that the forth ClientHello prompts the server to generate a new ServerHello flight. Looking at the contents of this ClientHello, we see that its message_seq field is 3.

Thanks! reproduction.tar.gz

[pfg666]

I opened a similar issue for Scandium, which also exhibited this behavior. From the discussions I had there, it appears that, there are rare situations when a conforming client may generate ClientHello messages with increased message sequence numbers.

This could be a reason for the server to accept these messages. I am leaving this issue open so that a developer can look at it, and close it if this is intended behavior. The same applies for the related issue I posted.

[ejohnstown]

Acknowledged.

[ejohnstown]

Your reproducer script sends the client hello with message_seq 2, and wolfSSL is treating that as a duplicate message and closing the session. The client hello with message_seq 3 is a new handshake as far as the server is concerned.

The issue is with the new handshake, the server should be sending the hello verify request with message_seq 3. This should be fixed with PR #5970.

I agree that having a client hello message with a message_seq greater than 0 is possible. The server could change its secret cookie value between sending hello verify request and getting the updated client hello. I believe the requirement that the client start with message_seq 0 is meant as a reasonable start of counting messages. The server doesn't start with 0, it uses the client's value. There isn't a requirement that the server has to check the message_seq and only accept them starting at 0.

I think this is now solved. Thank you for the report.