Send server ChangeCipherSpec when client offers a session id

[Frauschi]

Description

RFC 8446 Appendix D.4 says a TLS 1.3 server answers a ClientHello carrying a non-empty legacy_session_id with a ChangeCipherSpec. Both server send paths sat behind WOLFSSL_TLS13_MIDDLEBOX_COMPAT, which only --enable-tls13-middlebox-compat and --enable-jni define and neither enables by default, so a default-built server never sent one. Peers that require it, such as Erlang's ssl, abort with an unexpected_message alert.

Only wolfSSL-as-server was affected: the wolfSSL client sends an empty session id by default, so no peer is ever obliged to answer back. Reported as an SLH-DSA interop bug, but nothing in this path touches the certificate or sigalg and the regression test reproduces it with the stock test certs.

Changes

Both server sends now compile unconditionally, driven by the runtime tls13MiddleBoxCompat flag the server already clears for an empty session id, and are factored into one static SendTls13ServerChangeCipher().

• sentChangeCipher is compiled in for every TLS 1.3 build. SendChangeCipher() is now compiled for a TLS 1.3 server (or a middlebox-compat client), where before it went missing from a TLS 1.3-only build such as examples/configs/user_settings_tls13.h.
• Under TLS 1.3 the record no longer moves serverState in the OPENSSL_EXTRA block. That ran before any send could fail, leaving the server not waiting for the second ClientHello.
• A HelloRetryRequest is flushed as it is built, so the record behind it needs its own flush; without one a server grouping its messages sent a bare HelloRetryRequest.
• wolfSSL_clear() resets the flag, or a reused server answers only its first peer.
• The client sites take the same ordering, and the one answering a HelloRetryRequest keeps buildingMsg set when the send stops short; without that a refused write stranded the client handshake.

DTLS stays excluded, QUIC clears the flag per RFC 9001 Section 8.4, and with ECH the outer ClientHello decides since the inner hello is rebuilt carrying its session id. The configure and CMake option text now says client-side, since only that half stays behind the macro.

Behavioral change

A TLS 1.3 server now sends a ChangeCipherSpec it did not before, whenever the client offered a non-empty legacy_session_id; an empty one still gets none. One API difference: wolfSSL_get_state() no longer passes through WOLFSSL_SS_SERVER_CHANGECIPHERSPEC or WOLFSSL_SS_CLIENT_CHANGECIPHERSPEC on TLS 1.3, though the info callback still fires. What a client puts on the wire is unchanged. Written up in ChangeLog.md.

Testing

Eight tests in tests/api/test_tls13.c, seven of them ungated since default-build behaviour is the point: a non-empty session id gets exactly one record, an empty one gets none (#9156), a cleared server still answers its second peer, the HelloRetryRequest flight carries the record grouped and ungrouped while the flight after it carries none, and a refused-then-resumed write leaves exactly one on the wire on the straight-through, retry and client paths.

Each was verified to fail without its fix: reverting the source fails the two server tests, dropping the grouped-messages flush fails the HelloRetryRequest test, marking sentChangeCipher after a successful send fails the server retry test, and reverting the client HelloRetryRequest site fails the client test with the handshake never completing.

Clean in --enable-all, a default build, --enable-jni, --enable-tls13-middlebox-compat --enable-opensslextra --enable-hrrcookie, --enable-ech --enable-quic --enable-hrrcookie, a client-only TLS 1.3 build, user_settings_tls13.h, and CMake. make check passes on --enable-all.

Notes for reviewers

Two pre-existing things this surfaces but does not fix:

• ECH: ssl->session->sessionIDSz is reassigned on every ClientHello parse including the inner one, so with ECH accepted and a non-empty outer session id the ServerHello echoes an empty legacy_session_id_echo alongside the record. Predates this change, a conformant client rejects on that mismatch alone, and it is unreachable wolfSSL-to-wolfSSL.
• Sniffer: sniffer.c's change_cipher_spec case sets handShakeDone with no TLS 1.3 exclusion, but the branch above it sets serverCipherOn = 0 when srvKs.key_len == 0, so the recovery path it looks like it would trip never fires. Checked against a real capture carrying both a server and a client ChangeCipherSpec.

[wolfSSL-Bot]

Can one of the admins verify this patch?

[github-actions]

MemBrowse Memory Report

gcc-arm-cortex-m4-dtls13

• FLASH: .text +512 B (+0.3%, 186,748 B / 1,048,576 B, total: 18% used)

gcc-arm-cortex-m4-openssl-compat

• FLASH: .text +192 B (+0.0%, 780,540 B / 1,048,576 B, total: 74% used)

gcc-arm-cortex-m4-pq

• FLASH: .text +384 B (+0.1%, 301,404 B / 1,048,576 B, total: 29% used)

gcc-arm-cortex-m4-rsa-only

• FLASH: .text +192 B (+0.1%, 331,632 B / 1,048,576 B, total: 32% used)

gcc-arm-cortex-m4-tls13

• FLASH: .text +384 B (+0.2%, 242,017 B / 262,144 B, total: 92% used)

gcc-arm-cortex-m7-pq

• FLASH: .text +320 B (+0.1%, 302,300 B / 1,048,576 B, total: 29% used)

gcc-arm-cortex-m7-tls13

• FLASH: .text +384 B (+0.2%, 242,081 B / 262,144 B, total: 92% used)

linuxkm-standard

• Data: __patchable_function_entries +8 B (+0.0%, 49,672 B)
  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-min-ecc
• gcc-arm-cortex-m4-pkcs7
• gcc-arm-cortex-m4-sp-math
• gcc-arm-cortex-m4-tls12
• gcc-arm-cortex-m7
• linuxkm-pie
• stm32-sim-stm32h753

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #11306

Scan targets checked: wolfcrypt-rs-bugs, wolfssl-bugs, wolfssl-src

Fenrir result: Approved ✅

No new issues found in the changed files.

Advisory only — this automated result does not count as a GitHub approval.

[Frauschi]

Jenkins retest this please.

[philljj]

Skoll had a testing coverage nit (see below), otherwise ran clean.

Would like @julek-wolfssl to review this because he also just worked on middlebox-compat.

MEDIUM-1: Exercise the changed early-data CCS retry path

• File: src/tls13.c:15778-15784
• Function: wolfSSL_connect_TLSv13

Description: The PR changes the early-data path to guard and set sentChangeCipher before calling SendChangeCipher(), but the new client retry test covers only ordinary and HelloRetryRequest handshakes. It never enables early data or enters this branch. Moreover, the existing early-data WANT_WRITE callback in tests/api/test_tls13.c deliberately lets a standalone CCS write pass, so the default non-grouped configuration cannot detect a duplicate or stranded CCS here.

Code:

if (!ssl->options.dtls && !ssl->options.sentChangeCipher
        && ssl->options.tls13MiddleBoxCompat) {
    ssl->options.sentChangeCipher = 1;
    if ((ssl->error = SendChangeCipher(ssl)) != 0) {
        return WOLFSSL_FATAL_ERROR;
    }
}

Recommendation: Cover this third modified client send site with the same retry assertions already applied to the normal and HelloRetryRequest paths.

[Frauschi]

@philljj fixed your finding.

[Frauschi]

Jenkins retest this please

[philljj]

Might be a real unit test failure:

FAILURES:
   1686: test_tls13_early_data_0rtt_replay
 End API Tests
 Failed/Skipped/Passed/All: 1/396/1942/2339
FAIL scripts/unit.test (exit status: 1)

[Frauschi]

I cannot reproduce it. Jenkins retest this please.