UPSTREAM PR #30892: Reject empty TLS 1.3 HRR cookie#672
Conversation
RFC 8446 defines the Cookie extension as containing a non-empty cookie vector. The client-side HRR parser accepted a zero-length cookie because PACKET_memdup() treats an empty packet as success, which deferred failure until later in the handshake. Reject an empty cookie during HRR parsing with decode_error and add a regression test. Fixes #30868
OverviewAnalysis of 20,082 functions across 3 binaries reveals minimal performance impact: 1 modified, 0 new, 0 removed, 20,081 unchanged functions. Power consumption changes:
Function Analysis
Source code change: Commit f69f29c adds single-line validation 💬 Questions? Tag @loci-dev |
loci-dev
force-pushed
the
main
branch
5 times, most recently
from
421b135 to
770bf14
Compare
2 participants
Note
Source pull request: openssl/openssl#30892
Reject empty TLS 1.3 HelloRetryRequest Cookie extensions.
RFC 8446 defines the TLS 1.3 Cookie extension data as a Cookie structure containing
opaque cookie<1..2^16-1>, so a zero-length cookie vector is an out-of-range length and must be rejected with a fataldecode_error.The client-side HRR cookie parser accepted an empty cookie because
PACKET_memdup()succeeds for empty packets, leavingtls13_cookie_lenset to 0. The client could then continue after the malformed HRR and fail later with a misleading record-layer error.Add an explicit empty-cookie check in
tls_parse_stoc_cookie()before storing the parsed cookie, matching the handling used by nearby TLS 1.3 extension parsers.Also extend
70-test_tls13cookie.twith a regression test that rewrites the HRR Cookie extension to an empty vector and verifies that the client rejects it with a fataldecode_error.Fixes #30868
Testing:
HARNESS_JOBS=1 make test TESTS=test_tls13cookie