Fix max MTU logic in added test
Fix client and server SCTP argument. They should not be setting UDP. This was causing ./configure --enable-sctp --enable-dtls-mtu to fail on master.
With WOLFSSL_NO_MALLOC there is no allocator behind a NULL-heap XMALLOC,
so an allocation made outside any CTX or SSL object can only be served
from the global heap hint. wolfSSL_Init() makes such an allocation: under
OPENSSL_EXTRA it seeds the compatibility-layer RNG, whose _InitRng() call
allocates with a NULL heap. That returned NULL, wolfSSL_Init() reported
WC_INIT_E, and every wolfSSL_CTX_new_ex() that triggered the lazy init
failed, so neither example could establish a connection even though the
pool it had loaded was large enough.
Have each example nominate its own pool, which is what the hint is for.
The server could not do that before: it created its CTX through
wolfSSL_CTX_load_static_memory(), which loads the pool and creates the CTX
in one call, so wolfSSL_Init() ran before the caller ever saw the hint.
Load the pool with wc_LoadStaticMemory() and create the CTX afterwards, as
the client already does.
Claim the hint only when none is set, and drop it again on the way out.
Both pools are local to the example's own function, and testsuite runs the
wolfCrypt test, both examples and the echo server in one process, so an
example that overwrote the hint would leave it pointing at a pool that
dies the moment the example returns.
scripts/resume.test, scripts/tls13.test and testsuite/testsuite.test go
from failing to passing with --enable-staticmemory -DWOLFSSL_NO_MALLOC.
Restrict the claim to the standalone programs (!NO_MAIN_DRIVER). testsuite
and unit.test compile both examples with NO_MAIN_DRIVER and run server_test
on a spawned thread beside client_test, so an in-harness claim would publish
one thread's automatic-storage pool as the process allocator, let the other
thread allocate from it, and then revoke it when the owning frame unwound.
In those builds the harness's own long-lived pool is the one that belongs in
the hint.
Check ctx after wolfSSL_CTX_new_ex() rather than letting the following IO-pool
load report a CTX allocation failure as "unable to load static memory".
myEccKeyGen() generated the key share straight into the library's key object,
and myEccSharedSecret() is handed only the peer's key, so a TLS 1.3 client had
no private key left to reach and every handshake ended with:
wolfSSL_connect error -170, ECC input argument wrong type, invalid input
TEST_PK_PRIVKEY already kept the key on the application's side, which is what
a real PK-callback application does anyway; it just was not the default. Keep
it whenever the connection is TLS or DTLS v1.3 as well, and have the shared
secret callback pick the key by the same question its key gen asked, not by a
flag key gen has not set yet. The union holding it stops being
TEST_PK_PRIVKEY-only, and its comment stops naming TLS v1.2 as the version
that needs it.
Neither example zeroed its PkCbInfo, so hasKeyGen started as stack garbage.
Only the TEST_PK_PRIVKEY paths read it before, which hid that; zero it in
both.
scripts/pkcallbacks.test only ever ran the build's default version, and that
is TLS v1.2 wherever it is compiled in, so none of the above was covered. Run
the default and then each version the build has.
The option set ENABLED_TLSV12 to no, which the summary printed and a couple of
derived settings read, but nothing defined WOLFSSL_NO_TLS12, so every line of
the TLS 1.2 implementation was still compiled and still reachable. The one
place configure.ac adds that define sits in the FIPS lean-aesgcm bundle and is
guarded by "TLS 1.2 is still on and the user did not ask for it", which is
false exactly when --disable-tlsv12 was passed. Only the CMake build honoured
the switch.
Define it once the bundles have had their say, so --enable-tinytls13 and the
other bundles that turn the version off get it as well. The case guard keeps
the FIPS bundles from adding it twice.
Add three os-check entries for the configurations this makes reachable:
--disable-tlsv12 on its own, the same with DTLS 1.3, and the same with the
sniffer. The one existing entry that passes the option,
dtls13-client-minimal, already defined WOLFSSL_NO_TLS12 through CPPFLAGS and
strips most of the crypto along with it, so it never covered the option's own
effect.
Compiling the version out reaches code that assumed it was always there.
ProcessCSR_ex parses one certificate_status message and TLS 1.3 reads the
chain's per-certificate entries through it, so it moves out of the version
guard; only its TLS 1.2 wrapper stays behind. BuildMessage's connection-ID
size is read by the TLS 1.2 record path alone, so it is declared with it. The
tests and examples that hard-code a TLS 1.2 method, or a helper that only
those call, are skipped without the version.
CMake rejected three of the four combinations configure does but let
WOLFSSL_OLD_TLS=yes through, defined NO_OLD_TLS behind the user's back and
reported the option as still on. Reject it there too, and drop the NO_OLD_TLS
the block used to add, which the old-TLS option itself now always supplies.
With WOLFSSL_SNIFFER defined, the example client and server pin themselves to
a static RSA and static ECC cipher list so a capture can be decrypted. The
guard for that read "version < 4", meant to leave TLS 1.3 alone, but the
examples encode a DTLS version as a negative number and DTLS 1.3 is -4, so a
"-u -v 4" run was handed a TLS 1.2 only cipher list.
The server then found no common TLS 1.3 suite in MatchSuite_ex() while
processing the ClientHello and failed with MATCH_SUITE_ERROR, which reached
the client as a missing_extension alert. Every DTLS 1.3 handshake between the
two examples failed in a sniffer build, which also took out the DTLS cases of
scripts/ocsp-stapling_tls13multi.test. Only the examples were affected; an
application that does not set that cipher list was always able to handshake.
Allow a quantum-safe-only TLS 1.3 stack - ML-KEM key exchange with ML-DSA or
SLH-DSA authentication - with RSA, ECC and DH all disabled (the CNSA 2.0 /
EO 14412 posture).
- Treat a usable standalone ML-KEM group as a valid key exchange and
Falcon/ML-DSA/SLH-DSA as valid authentication, so the "no cipher suites"
#errors no longer fire (ssl.c, internal.h), and extend the CopyDecodedToX509
pkCurveOID guard to match the struct member guards (internal.c).
- asn.c: guard the RSA/ECC-only certificate signing helpers so cert generation
compiles with RSA and ECC disabled, while keeping MakeSignatureCb available
for the WOLFSSL_CERT_SIGN_CB (TPM/HSM) offload path.
- tls.c: advertise the psk_dhe_ke exchange mode when a standalone ML-KEM group
is usable on the client side, that is when the build has both key generation
and decapsulation. Without it an ML-KEM-only build fell back to psk_ke, the
resumption key schedules diverged, and the first AEAD record failed to
authenticate (AES_GCM_AUTH_E), breaking session-ticket resumption.
- tls13.c: hoist the hashAlgo void cast in EncodeSigAlg out of the Ed25519 and
Ed448 cases so a build with no classic signature algorithm still marks the
parameter used.
- Examples and tests: add ML-DSA and SLH-DSA certificate selection (gated on
NO_RSA so it only applies in true PQC-only builds) and default to TLS 1.3
when no classic auth is built in and a post-quantum signature is available
(test.h, client/server/echo*, test_tls13.c). SLH-DSA uses the SHAKE-128s leaf
certificates and their shared 128s root.
- CI: add PQC-only entries to the pq-all.json config list (ML-DSA and SLH-DSA),
each exercising the build, a full TLS 1.3 handshake, and ML-KEM-only
session-ticket resumption.
Whether a build can authenticate with a post-quantum certificate is three
separate questions - is the algorithm compiled in, are test credentials wired
up for the enabled parameter set, and can this build sign - so test.h answers
them with three tiers of macro rather than testing WOLFSSL_HAVE_MLDSA and
WOLFSSL_HAVE_SLHDSA directly:
- TEST_HAVE_MLDSA_CERT_FILES / TEST_HAVE_SLHDSA_CERT_FILES: the credential
paths name real files. ML-DSA needs an enabled parameter level; SLH-DSA needs
a 128s parameter set, since both families share a 128s root and only those
certificates are wired up, and PEM decoding, since the entity certificates
ship as PEM only. Loading a certificate needs verification support alone, so
test_tls13.c uses this tier - it only needs a certificate on the context.
- TEST_HAVE_MLDSA_CERTS / TEST_HAVE_SLHDSA_CERTS: the above, plus the ability
to sign. A verify-only build derives WOLFSSL_MLDSA_NO_SIGN and drops private
key support entirely, so it can neither load the key nor produce a
CertificateVerify. The example credential ladders use this tier.
- TEST_HAVE_PQC_CERT_AUTH: either of those, plus WOLFSSL_TLS13. Both algorithms
are TLS 1.3 only, so folding the version into the macro keeps the version
defaults and the PSK fallbacks in the client, server and echo examples from
disagreeing. Falcon is deliberately absent, having no credentials in the
ladders, so a Falcon-only build keeps the historic TLS 1.2 PSK behavior.
A build that fails a gate now falls back to PSK instead of naming credentials
it cannot use, which removes two hard #errors that were reachable from
configure: --enable-slhdsa with only non-128s parameter sets broke every build
that includes test.h, even ones with RSA and ECC enabled that would never touch
an SLH-DSA credential.
Also in the credential material and the configurations this opens up:
- test.h: pair the DER ML-DSA certificate with mldsa<N>-key.der. The
mldsa<N>_priv-only.der files are standalone PKCS#8 encoding vectors from an
unrelated key pair, so a build without PEM decoding presented a certificate
and signed with a key that did not match it, and the peer rejected the
CertificateVerify.
- echoserver.c: load the SLH-DSA key with CERT_FILETYPE like every neighboring
branch, rather than hardcoding WOLFSSL_FILETYPE_PEM against a certificate
loaded in the build-dependent format.
- internal.c, tls13.c, ssl_load.c: mark ssl, sigOut, keyType and keySz used.
Every reader of these sits in a per-algorithm block, so a build with no
signing algorithm at all left them unused and -Werror rejected the library.
- tests/api.c: skip test_wolfSSL_PKCS8 unless RSA, ECC or PEM decoding is
available. With none of them every key-loading body compiles out, leaving the
file locals unused and nothing for the test to do.
Extend the swdev callback to handle ECC operations: keygen, ECDH, sign,
verify, get-size, get-sig-size.
Relax WOLF_CRYPTO_CB_ONLY_ECC guards in the test suite so that tests run
under swdev, and wire wc_SwDev_Init/Cleanup into testsuite, client, and
server. Two tests are intentionally kept excluded even with swdev because
they call raw ECC math primitives (wc_ecc_mulmod, on-curve validation in
wc_ecc_import_x963) that are stripped below the cryptocb dispatch layer:
- ecc_mulmod_test (wolfcrypt/test/test.c)
- test_wc_ecc_import_x963_off_curve (tests/api/test_ecc.c)
Windows test code pre-picked a random port via GetRandomPort() (returning
a value in [49152, 65535]) before calling bind(), with no check that the
port was free and no retry on collision. Under load this occasionally
collided with an already-bound port and aborted the test with
"tcp bind failed", producing intermittent Jenkins failures (e.g. PRB
windows-test-v2 #17140 in the OCSP responder test).
The Unix path already does the right thing: bind to port 0 (OS-assigned
ephemeral) and read the port back via getsockname(). The same primitives
exist in Winsock 1.1, so drop the USE_WINDOWS_API guard around the
getsockname block in tcp_listen()/udp_accept() and remove the per-caller
GetRandomPort() workarounds in the OCSP responder, server example, and
the api.c / test_ossl_bio.c test sites. socklen_t is already typedef'd
as int on Windows in test.h.
GetRandomPort() itself is left in place since it is a static inline in a
shipped public test header.
RFC 8446 section 8 requires any server instance to accept 0-RTT for a
given ClientHello at most once. Prior to this change wolfSSL's behaviour
diverged from that requirement in several ways:
* ctx->maxEarlyDataSz defaulted to MAX_EARLY_DATA_SZ whenever the
library was built with WOLFSSL_EARLY_DATA, so servers auto-
advertised 0-RTT in NewSessionTicket without the application
asking. RFC 8446 E.5 says 0-RTT MUST NOT be enabled unless
specifically requested.
* The post-accept eviction is compiled out under NO_SESSION_CACHE,
so builds without the cache accepted 0-RTT with no replay defence.
* Stateless self-encrypted tickets do not carry a session ID on the
stateless DoClientTicket decrypt path, so wolfSSL_SSL_CTX_remove_
session could not locate them to evict.
* wolfSSL_SSL_CTX_remove_session always returned 0 on success
regardless of whether the session was actually in the cache,
diverging from OpenSSL's SSL_CTX_remove_session (1 on success,
0 on not-found).
Changes:
* src/internal.c: ctx->maxEarlyDataSz defaults to 0; applications
must opt in with wolfSSL_CTX_set_max_early_data.
* src/tls13.c: #error when WOLFSSL_EARLY_DATA is built with
HAVE_SESSION_TICKET and NO_SESSION_CACHE. Escape hatch
WOLFSSL_EARLY_DATA_NO_ANTI_REPLAY for deployments that take
application-layer responsibility.
* wolfssl/internal.h: imply WOLFSSL_TICKET_HAVE_ID from
WOLFSSL_EARLY_DATA so stateless-ticket issuance populates the
cache under an ID that eviction can find.
* src/ssl_sess.c: wolfSSL_SSL_CTX_remove_session returns 1 when the
session was found (internal-cache hit, or ctx->rem_sess_cb fired
for an external cache), 0 otherwise. Matches OpenSSL semantics.
* src/tls13.c: the 0-RTT acceptance condition in CheckPreSharedKeys
now calls wolfSSL_SSL_CTX_remove_session and checks its return:
the eviction is the check. If the session was in the cache, 0-RTT
is accepted and the single-use requirement is satisfied. If not,
the early_data extension is rejected through the normal path so
the record layer correctly skips in-flight 0-RTT records.
WOLFSSL_MSG at each rejection site.
* doc/dox_comments/header_files/ssl.h: document runtime opt-in.
* tests: four new tests —
test_tls13_0rtt_default_off (fails without default-to-0 fix),
test_tls13_0rtt_stateless_replay (fails without TICKET_HAVE_ID
implication and remove_session gate),
test_tls13_remove_session_return (fails without return-value fix),
test_tls13_0rtt_ext_cache_eviction (fails without ext-cache
counts-as-found fix).
test_tls13_early_data explicitly opts in via
wolfSSL_CTX_set_max_early_data.
tests/api.c: two SSL_CTX_remove_session == 0 assertions updated
to == 1.
Implement RFC8773bis (draft-ietf-tls-8773bis-13)
cert_with_extern_psk for TLS 1.3, including protocol checks
and API support.
Includes unit tests for API and handshake behavior as well
as tests in the testsuite using extended examples.
wolfssl/ssl.h, examples/client/client.c, examples/server/server.c, src/bio.c, tests/api.c: add error tracing for WOLFSSL_SHUTDOWN_NOT_DONE.
tests/api.c: in test_wolfSSL_read_write_ex(), use WOLFSSL_SUCCESS rather than 1 for expected-success wolfSSL_shutdown()s, and add note that the wrong value is being returned (the test currently always fails, which is masked by an always-success retval).
* Enable ML-KEM by default in build systems (autoconf and CMake)
* Only allow three to-be-standardized hybrid PQ/T combinations by
default
* Use X25519MLKEM768 as the default KeyShare in the ClientHello (if user
does not override that). When Curve25519 is disabled, then either
WOLFSSL_SECP384R1MLKEM1024 or WOLFSSL_SECP256R1MLKEM768 is used as
default depending on the ECC configuration
* Disable standalone ML-KEM in supported groups by default (enable with
--enable-tls-mlkem-standalone)
* Disable extra OQS-based hybrid PQ/T curves by default and gate
behind --enable-experimental (enable with --enable-extra-pqc-hybrids)
* Reorder the SupportedGroups extension to reflect the preferences
* Reorder the preferredGroup array to also reflect the same preferences
* Add async support for ML-KEM hybrids
* DTLS 1.3 cookie and CH frag handling
* static memory handling
* Fix memory leak in TLS server PQC handling in case of ECH
* Make sure hybrids are actually tested in testsuite
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 both TLS 1.3 and Brainpool curves are enabled, three new groups can
be used for the ECDHE key exchange according to RFC 8734:
* WOLFSSL_ECC_BRAINPOOLP256R1TLS13 (31)
* WOLFSSL_ECC_BRAINPOOLP384R1TLS13 (32)
* WOLFSSL_ECC_BRAINPOOLP512R1TLS13 (33)
Also ensure that the existing TLS 1.2 curves are sent properly.
The TLS client application is updated to support handshakes via
Brainpool curves using the new argument "--bpKs".
add WC_GENERATE_SEED_DEFAULT, which defaults to wc_GenerateSeed if not overridden, and replace wc_GenerateSeed with WC_GENERATE_SEED_DEFAULT in various calls to wc_SetSeed_Cb();
linuxkm/linuxkm_wc_port.h: if FIPS <v6 and RDSEED, define WC_LINUXKM_RDSEED_IN_GLUE_LAYER and define WC_GENERATE_SEED_DEFAULT wc_linuxkm_GenerateSeed_IntelRD;
wolfcrypt/test/test.c: update rng_seed_test() with gating and vectors for FIPS v5 with HAVE_AMD_RDSEED or HAVE_INTEL_RDSEED;
wolfssl/wolfcrypt/types.h: add WC_HAVE_VECTOR_SPEEDUPS helper macro, and enlarge fallthrough definition coverage for DISABLE_VECTOR_REGISTERS.
Add support for X25519 and X448 based hybrid PQC + ECC key exchange
groups. Furthermore, two new combinations with SECP curves are added to
match OQS combinations.
This also incorporates the changed order of X25519 and X448 based
combinations to place the PQC material before the ECDH material. This is
motivated by the necessity to always have material of a FIPS approved
algorithm first.
Also, codepoints are updated to reflect the latest draft standards for
pure ML-KEM and some of the hybrids. With these changes and based on the
recent additions to both enable ML-KEM final and draft versions
simultaneously, a WolfSSL TLS server is now compatible with all recent
browsers that support either the draft version of ML-KEM (Chromium based
browsers and Firefox < version 132; only when the draft version is
enabled in the build) or the final version already (Firefox > version 132).
In the process of extending support, some code and logic cleanup
happened. Furthermore, some memory leaks within the hybrid code path have
been fixed.
Signed-off-by: Tobias Frauenschläger <tobias.frauenschlaeger@oth-regensburg.de>
