wolfSSL
[Bug]: DTLS Anti-Replay Mechanism Corner Cases
Version
v5.6.3-stable
Configuration:
./configure --disable-asm --enable-singlethreaded --enable-dtls --enable-dtls-mtu --enable-psk-one-id --enable-psk --enable-static --disable-extended-master --enable-opensslextra --enable-tlsv10 --enable-debug --enable-nullcipher --enable-all-crypto
Expected Behavior 1
The DTLS 1.2 RFC specifies the following regarding record sequence numbers:
For each received record, the receiver MUST verify that the record contains a sequence number that does not duplicate the sequence number of any other record received during the life of this session. ...
Actual Behavior 1
During an interaction, if the server receives a ClientKeyExchange message with a record sequence number that duplicates the sequence number of a previously processed ClientHello, it continues with the handshake without enforcing the expected requirement.
PoC 1
Please check the attached PCAP file for an example interaction.
Actual Behavior 2
The same issue occurs when the server receives the second ClientHello with a duplicate sequence number.
PoC 2
Please check the attached PCAP file for an example interaction.
Upon closer examination of the interaction described above, another deviation from the RFC guidelines becomes evident.
Expected Behavior 2
According to the Errata for DTLS 1.2, we know that:
In order to avoid sequence number duplication in case of multiple HelloVerifyRequests, the server MUST use the message_seq in the ClientHello as the message_seq in the HelloVerifyRequest.
Similarly, The errata states:
In order to avoid sequence number duplication in case of multiple cookie exchanges, the server MUST use the message_seq in the ClientHello as the message_seq in its initial ServerHello.
Actual Behavior 3
WolfSSL mistakenly implements this requirement for the record sequence number as well (As originally was expected by the RFC, but fixed later).
PoC 3
Looking at the attached example interaction, the server use the record sequence number in the ClientHello as the record sequence number in its initial ServerHello.
Hi @bathooman , I've assigned @rizlik and @julek-wolfssl to have a look at this. Please stay tuned in case they have questions for you. In the mean time, can you let us know a bit about yourself? Is this project academic, professional or personal in nature? At wolfSSL, we love knowing how people are using our software so please feel free to share as much as you want.
Warm regards, Anthony
Hello @anhu
The testing was conducted as part of an academic project.
Additional observation:
I also evaluated versions 5.3.0 and 5.6.6.
Interestingly, while the mentioned issues persist in version 5.6.6, they do not occur in version 5.3.0. Therefore, I suspect that some changes in between created the issue.
Thank you.
Hi @bathooman , Thanks for reporting this. The behaviors are the results of the stateless parsing of the first ClientHello. We are evaluating some way to fix the issues. I'll keep this issue updated.
Hi @bathooman,
https://github.com/wolfSSL/wolfssl/pull/7466 fixes scenario 1 by marking all record sequence numbers from before stateful parsing as read. Scenarios 2 and 3 are the expected outcomes for a DTLS server to be able to operate statelessly. Otherwise, we would have to maintain state for every incoming ClientHello.
Juliusz
