F-5813: clarify BuildMessage sequence-number wrap comment

The sequence number 2^64-1 is itself RFC 5246 6.1-legal; only the wrap to 0
is forbidden. GetSEQIncrement reads the current counter then post-increments
it, so the check refuses the final legal sequence number to avoid the
wrapping post-increment. Document that this last value is deliberately
sacrificed rather than implying 2^64-1 is itself unusable.
This commit is contained in:
Juliusz Sosinowicz
2026-06-11 19:22:36 +00:00
parent 108afdf1c3
commit e68cc75ecd
+5 -5
View File
@@ -24777,11 +24777,11 @@ int BuildMessage(WOLFSSL* ssl, byte* output, int outSz, const byte* input,
#endif
#ifndef WOLFSSL_NO_TLS12
/* RFC 5246 6.1: record sequence numbers MUST NOT wrap. Refuse to emit a
* record once the write sequence number has reached its maximum value
* (2^64-1); reusing sequence number 0 with the same keys would break the
* record protection. The caller must renegotiate or close the connection
* instead. DTLS sequence numbers are epoch-scoped and handled elsewhere. */
/* RFC 5246 6.1: sequence numbers MUST NOT wrap. GetSEQIncrement post-
* increments, so refuse at hi == lo == 0xFFFFFFFF (2^64-1): that last legal
* value is deliberately sacrificed to avoid wrapping to 0 and reusing
* sequence number 0. The caller must renegotiate or close. DTLS sequence
* numbers are epoch-scoped and handled elsewhere. */
if (!sizeOnly && !ssl->options.dtls &&
ssl->keys.sequence_number_hi == 0xFFFFFFFFU &&
ssl->keys.sequence_number_lo == 0xFFFFFFFFU) {