TLS 1.3: compare the 0-RTT fresh start reference against a whole second

[Frauschi]

Problem

test_tls13_early_data_0rtt_replay fails intermittently on Linux CI, roughly once every few hundred runs, with:

ERROR - tests/api/test_tls13.c line 5238 failed with:
    expected: earlyRead == sizeof(earlyMsg)
    result:   0 != 16

The ExpectTrue(wolfSSL_session_reused(ssl_s)) immediately above it passes, so the session resumes and only the early data goes missing. It has been written off as a flaky test twice (PR #11306 in August, PR #11352 this week, on unrelated configurations). It is not flaky - it is a real refusal of 0-RTT by the server.

Root cause

The RFC 8446 section 8.2 fresh start check flags a resumption ticket as belonging to a previous server instance when ticketSeen is below ctx->ticketStartTime (src/tls13.c ~6727). Those two values are read from different clocks:

Value	Read from	Resolution
ctx->ticketStartTime	TimeNowInMilliseconds() -> gettimeofday(), floored to a whole second (src/internal.c ~2665)	fine grained
ticketSeen	sess->bornOn * 1000, and bornOn is LowResTimer() -> XTIME(0) -> time()	coarse seconds

On glibc/Linux time() reads the coarse realtime seconds (vDSO xtime_sec, refreshed on the timer tick) while gettimeofday() adds the elapsed delta since that refresh. For up to one tick after each second boundary - 1 ms at CONFIG_HZ=1000, 4 ms at 250 - gettimeofday() already reports second S while time() still returns S-1.

A WOLFSSL_CTX created inside that window records ticketStartTime = S * 1000. A session born microseconds later records bornOn = S - 1, so ticketSeen = (S - 1) * 1000, which is lower. ticketPredatesCtx is set and DoPreSharedKeys skips early data at src/tls13.c:7000. The PSK itself is still accepted, which is why the handshake resumes and only the early data vanishes.

The && chain short-circuits before wolfSSL_SSL_CTX_remove_session(), so the single-use eviction never runs either.

The check landed in 978d795 / 1e46767 / cbcaf31. cbcaf31 already added exactly this mitigation - drop a further whole second - but guarded it to WOLFSSL_32BIT_MILLI_TIME, for the unrelated reason that 2^32 is not a multiple of 1000, so a wrapped 32 bit ms clock keeps its true sub-second part through the % 1000. The 64 bit path never got it.

Fix

Lift the guard so the same-second tolerance applies on every platform:

ctx->ticketStartTime -= ctx->ticketStartTime % 1000;
if (ctx->ticketStartTime > 1000) {
    ctx->ticketStartTime -= 1000;
}

The cost is that a ticket minted in the second before the ctx was created is now accepted for 0-RTT. That is immaterial for a heuristic about freshly started servers, and it is the tolerance the 32 bit path has been running with since cbcaf31.

Reproducing it

It does not reproduce where time() and gettimeofday() are coherent, which covers macOS and the usual container VMs - hence 380+ runs in August and, this week, 100 group runs on arm64, 40 full --api sweeps on an x86_64 build whose skip/pass fingerprint matches the failing Jenkins build exactly, and 4 million in-process iterations, all clean.

Injecting the coarse clock reproduces it on demand. An LD_PRELOAD shim that makes time() lag gettimeofday() for the first LAG_US microseconds of each second:

time_t time(time_t *t) {
    struct timeval tv;
    long win = getenv("LAG_US") ? atol(getenv("LAG_US")) : 3000;
    gettimeofday(&tv, 0);
    time_t s = tv.tv_sec - (tv.tv_usec < win ? 1 : 0);
    if (t) *t = s;
    return s;
}

unit.test deduplicates repeated -<testname> arguments, so to get iteration density the test body was temporarily wrapped in a repeat loop (360 iterations/sec in process, against 7.6/sec one process per run). That harness change is not part of this PR.

Run	Before	After
LAG_US=0, 300 iterations	clean	clean
LAG_US=3000 (a realistic Linux tick), 20000 iterations	fails at iteration 135	clean
LAG_US=500000, 5000 iterations	fails at iteration 165	clean
LAG_US=500000 with wolfSSL_CTX_no_early_data_fresh_start_check()	clean	-

The third row isolates the gate: disabling only the fresh start check makes the failure go away under the same injected skew.

Testing

• --enable-all --enable-debug on macOS/arm64: tls13 group 124 passed, 15 skipped, 0 failed; make check clean.
• x86_64 Linux, --enable-sp-math-all --enable-all --enable-intelasm --enable-sp-asm --enable-smallstack --enable-stacksize=verbose (the configuration that failed in CI): full --api sweep 0/431/2068/2499.
• test_tls13_0rtt_fresh_start and test_tls13_0rtt_fresh_start_check_args still pass, so the check itself still rejects tickets that genuinely predate the ctx.
• 20000 iterations under the injected 3 ms skew, where the unfixed build failed within 135.

No new test: exercising this in the suite needs the clock injected, which the harness has no mechanism for.

[wolfSSL-Fenrir-bot]

Fenrir Automated Review — PR #11379

Scan targets checked: 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.

[github-actions]

MemBrowse Memory Report

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-openssl-compat
• gcc-arm-cortex-m4-pkcs7
• gcc-arm-cortex-m4-pq
• gcc-arm-cortex-m4-rsa-only
• gcc-arm-cortex-m4-sp-math
• gcc-arm-cortex-m4-tls12
• gcc-arm-cortex-m4-tls13
• gcc-arm-cortex-m7
• gcc-arm-cortex-m7-pq
• gcc-arm-cortex-m7-tls13
• linuxkm-pie
• linuxkm-standard
• stm32-sim-stm32h753