Record Sequence Number non-conformance bug
bathooman opened this issue · comments
Description
- Type: Non-conformance Bug
- Priority: Minor
Non-conformance Bug
Version: development branch
Expected behavior
The DTLS RFC specifies the following regarding the record sequence number:
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. Duplicates are rejected through the use of a sliding receive window. The "right" edge of the window represents the highest validated sequence number value received on this session. Records that contain sequence numbers lower than the "left" edge of the window are rejected.
Actual behavior
One can complete a handshake with the following values for the record sequence number:
CH0.sequence_number = 0
CH2.sequence_number = 68
CKE.sequence_number = 0
CCC.sequence_number = 0
The problem also exists when the server sends records with non-unique record sequence numbers.
I have attached the completed handshake trace for the mentioned non-conformance.
Just to mention, that's not without doubt.
The receive window is updated only if the MAC verification succeeds.
But in epoch 0, there is no MAC to validate. As consequence, there is a extremely little chance for an spoofing attacker to block the handshake sending messages with future record sequence number, as
Records that contain sequence numbers lower than the "left" edge of the window are rejected.
Eclipse/Californium uses that Anti-Reply mechanism, but I'm not completely confessed, that this has advantages over not doing so in epoch 0.
Analyzing the code, the issue seems to be limited to the record sequence number 0. That is used for restart, unfortunately without additional checks (e.g. verified CLIENT_HELLO).
The issue has in my opinion two parts:
- the first considers the "stateless" ClientHello phase. In that, no record_sequence filter could be applied, because there is no state to apply to.
- the second considers the "stateful" phase starting with CH2.
PR #89 has addressed the stateless parts, and PR #117 addresses some leftovers in the record_sequence filter.
If possible, you may retest with that PR #117 and verify, that for the messages starting with CH2 the issue is fixed.
The issue is resolved. I close this issue.