OCSP Responder Core API:
- Add new public API for creating and managing an OCSP responder
- Add public wrappers for internal OCSP request/response functions
- OcspRespCheck: fix check when authorized responder is loaded into CM
Header Cleanup:
- Remove circular dependency when including `#include <wolfssl/wolfcrypt/asn.h>` from wolfssl/wolfcrypt/ecc.h and wolfssl/wolfcrypt/rsa.h
OCSP Responder Example (examples/ocsp_responder/):
- Add a command-line OCSP responder for interoperability testing with OpenSSL's `openssl ocsp` client
Test Scripts (scripts/):
- ocsp-responder-openssl-interop.test: Tests wolfSSL OCSP responder with `openssl ocsp` client
- ocsp-stapling-with-wolfssl-responder.test: Tests wolfSSL OCSP responder when doing OCSP stapling
Certificate Infrastructure (certs/ocsp/):
- Add DER-format certificates and keys for OCSP testing
- Update renewcerts.sh to generate DER versions
Known Limitations (documented in src/ocsp.c header comment):
- Single request/response per OCSP exchange only
- Key-hash responder ID only (no name-based responder ID)
- No singleExtensions support
When a server uses a HRR to negotiate the key exchange group to use, the
selected group is advertised in the HRR key share extension.
Furthermore, this group is also stored in the Cookie that is sent to the
client. When the server receives the second CH, the group used in the
key share extension MUST be the one of the HRR.
For stateless DTLS servers, the handling of this check had a bug. The
key share group of the HRR is stored in the ssl->hrr_keyshare_group
variable and is checked against the received key share of the second CH.
However, in the stateless server case, another CH message may be
received inbetween the two CH message of the desired client, potentially
overwriting the ssl->hrr_keyshare_group variable. This then causes
handshake failures when the ssl->hrr_keyshare_group variable contains
another group than the second CH message of the desired client.
To fix this, the following changes are conducted:
1. Disable the ssl->hrr_keyshare_group check for stateless DTLS 1.3
servers. As long as the server is stateless, CHs from multiple
clients may be received that individually cause HRRs with different
groups. For each of these clients, the HRR group is properly stored
in the cookie.
2. When a valid cookie is received from the client, the server becomes
stateful. In this case, we now parse the cookie for a stored HRR
group in the RestartHandshakeHashWithCookie() method. If present,
we restore the ssl->hrr_keyshare_group variable to this group to
ensure the error checks succeed.
3. Move the check of ssl->hrr_keyshare_group of the the KeyShare
extension parsing logic into the general TLS1.3 ClientHello parsing
after extension handling. This ensures that the order of the cookie
and key share extensions does not matter.
A new test is added to check for this behavior.
In ImportKeyState(), wordAdj was always zero because it was computed
after clamping wordCount, and the subtraction direction was reversed.
This caused misaligned parsing of all subsequent fields when importing
state from a peer compiled with a larger WOLFSSL_DTLS_WINDOW_WORDS.
Fix both window and prevWindow blocks to compute the adjustment before
clamping, with the correct subtraction direction.
Add test that imports a state buffer with wordCount > WOLFSSL_DTLS_WINDOW_WORDS
to verify the fix.
Add missing bounds validation in wolfSSL_select_next_proto. Three
issues fixed:
1. Outer loop: no check that length byte + position stays within inLen,
allowing XMEMCMP to read past the server protocol list buffer.
2. Inner loop: same missing check for clientNames/clientLen boundary.
3. No-overlap fallback unconditionally dereferences clientNames[0] even
when clientLen is 0, and returns an outLen that may exceed the buffer.
Also reject zero-length protocol entries (invalid per RFC 7301) to
prevent infinite loops.
Add unit test test_wolfSSL_select_next_proto with 8 cases covering NULL
params, normal match, no overlap, malformed length overruns, zero-length
entries, and empty client lists.
The while loop conditions in TLSX_TCA_Find were inverted, causing two
bugs: the loop short-circuited on type match alone without checking the
id content, and the XMEMCMP sense was reversed (continuing on match,
stopping on mismatch). This meant any TCA entry with a matching type
would be returned as a match regardless of whether the identifier
actually matched.
Restructure the loop to correctly require both type and id (size +
content) to match before returning an entry, and to match any entry
immediately for PRE_AGREED type.
Add test_TLSX_TCA_Find unit test exercising exact match, mismatched id,
and PRE_AGREED cases via memio handshake.
## Summary
- Add non-blocking (incremental) Curve25519 key generation and shared secret via `WC_X25519_NONBLOCK`, modeled after the existing ECC non-blocking pattern (`WC_ECC_NONBLOCK`)
- Implement `curve25519_nb()` and `fe_inv__distinct_nb()` in `fe_low_mem.c` as state-machine variants that return `FP_WOULDBLOCK` to yield after each field multiply
- Add `wc_curve25519_set_nonblock()` API to attach/detach non-blocking context to a key
- Integrate X25519 non-blocking with TLS 1.2/1.3 key share generation and shared secret in `tls.c` and `internal.c` (behind `WC_X25519_NONBLOCK && WOLFSSL_ASYNC_CRYPT_SW`)
- Add `--enable-curve25519=nonblock` configure option (auto-enables `--enable-asynccrypt` and `--enable-asynccrypt-sw`)
- Add X25519 async software dispatch cases in `async.c` and types in `async.h`
- Fix async guard in `curve25519.c` to require `WOLFSSL_ASYNC_CRYPT_SW` (matching other algorithms)
- Overhaul `examples/async/` client/server: non-blocking I/O via `WOLFSSL_USER_IO`, standalone `Makefile`, X25519/ECC mode selection, CI-friendly ready-file sync
- Add `examples/configs/user_settings_curve25519nonblock.h` and CI coverage in `os-check.yml` and new `async-examples.yml` workflow
- Add wolfcrypt test and API test coverage for X25519 non-blocking