[embhorn]

Description

Split the ticket into several records when it is larger than the negotiated max fragment length.

Fixes #11079

Testing

Added a regression test.

Checklist

• added tests
• updated/added doxygen
• updated appropriate READMEs
• Updated manual and documentation

[Copilot]

Copilot review overview

🟡 Changes recommended

The regression test can pass without exercising fragmentation when the generated ticket fits in one record.

Review effort: Balanced
Findings: 1

Open (1)

• Ensure regression test always requires fragmented session tickets · New

What changed in this PR

Adds TLS 1.3 NewSessionTicket fragmentation to respect negotiated record limits.

Changes:

• Fragments oversized tickets across adjacent TLS records.
• Updates ticket-size rationale for resumed ClientHello messages.
• Adds a fragmentation and resumption test.

File	Description
src/​tls13.c	Implements ticket fragmentation.
src/​internal.c	Updates the peer-certificate exclusion rationale.
tests/​api/​test_tls13.c	Adds the regression test.
tests/​api/​test_tls13.h	Registers the new test.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

MemBrowse Memory Report · Explore what changed →

gcc-arm-cortex-m4-openssl-compat

• FLASH: .text +192 B (+0.0%, 796,316 B / 1,048,576 B, total: 76% used)

gcc-arm-cortex-m4-pq

• FLASH: .text +256 B (+0.1%, 311,952 B / 1,048,576 B, total: 30% used)

gcc-arm-cortex-m4-rsa-only

• FLASH: .text +192 B (+0.1%, 342,600 B / 1,048,576 B, total: 33% used)

gcc-arm-cortex-m4-tls13

• FLASH: .text +192 B (+0.1%, 248,866 B / 262,144 B, total: 95% used)

gcc-arm-cortex-m7-pq

• FLASH: .text +192 B (+0.1%, 312,784 B / 1,048,576 B, total: 30% used)

gcc-arm-cortex-m7-tls13

• FLASH: .text +256 B (+0.1%, 248,930 B / 262,144 B, total: 95% used)

zephyr-frdm_rw612

• FLASH: log_const_area -8 B, rodata -8 B, text +1,600 B (+0.6%, 284,048 B / 67,108,864 B, total: 0% used)

No memory changes detected for:

• gcc-arm-cortex-m0plus
• gcc-arm-cortex-m3
• gcc-arm-cortex-m4
• gcc-arm-cortex-m4-baremetal
• gcc-arm-cortex-m4-crypto-only
• gcc-arm-cortex-m4-dtls13
• gcc-arm-cortex-m4-min-ecc
• gcc-arm-cortex-m4-pkcs7
• gcc-arm-cortex-m4-sp-math
• gcc-arm-cortex-m4-tls12
• gcc-arm-cortex-m7
• stm32-sim-stm32h753

---

_{Catch memory regressions in CI with MemBrowse. Free for open source.}

[rizlik]

The current situation is that:

• wolfSSL server defragments CH1 and CH2.
• wolfSSL client never fragments CH1/CH2, but both CH1 and/or CH2 can exceed the offered max fragment limit. However, Max Fragment Length isn't negotiated yet when CH2 is sent (the server acknowledges the extension in EE), so exceeding that offered limit isn't violating the RFC. Nevertheless, wolfSSL (and OpenSSL) enforces the reduced limit early, so it would be better to enable CH fragmentation. This can also be an opportunity to consolidate TLS 1.3 fragmentation into shared helpers and enable fragmentation for EE, HRR, CertificateRequest, and SH as well.

It can be done in a follow-up PR.

[embhorn]

Agreed on follow-up work

[rizlik]

consider using a custom SessionTicketEncCb to enforce a ticket that always exceed the limit.

[philljj]

Retest this please.

(fipsv2 test was disrupted)

[rizlik]

update the header comment in https://github.com/embhorn/wolfssl/blob/78a1446254161cc89d64864335103e43571a3b37/doc/dox_comments/header_files/ssl.h#L6279