When resuming a session wolfSSL_SetSession unconditionally
overwrote ssl->version with the version stored in the cached
session, even if that version was below the WOLFSSL's configured
minDowngrade. The overwritten version then fed straight into
SendClientHello, so a client configured to require TLS 1.2 or
higher could still emit a ClientHello advertising e.g. TLS 1.0
when resuming an old cached session. The ServerHello path catches
the actual downgrade, but the ClientHello version is already a
protocol-conformance issue and can confuse middleboxes.
Reject the session if its stored minor version is below
ssl->options.minDowngrade. The check is DTLS-aware: DTLS minor
versions decrease as the protocol version increases, so the
direction of the comparison is flipped for DTLS.
F-2105
* in pbkdf2_test(), pwdbased_test(), and pkcs12_test(), add missing FIPS v7+
gates around stanzas that use wc_PBKDF_max_iterations_set() and
wc_PBKDF_max_iterations_get() or depend on erroring for excessive PBKDF
iterations (fixes#10050);
* in ecc_test_buffers(), omit new corrupt HMAC tag test on FIPS <v6 (fixes
8f2a3f9563).
tests/api/test_dtls.c: add FIPS v7+ gate to test_dtls13_frag_ch2_with_ch1_rtx().
wolfssl/wolfcrypt/memory.h: #include "../../linuxkm/linuxkm_memory.h" rather than "linuxkm/linuxkm_memory.h", following pattern in wc_port.h.
* 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
Order of preference, based on algorithms compiled in, to use with HMAC
for TLS 1.3 cookie:
1. SHA-256
2. SHA-384
3. SHA-512
4. SM3
Make code compile and unittest pass when SHA-256 not compiled in.
Certificates used for testing require SHA-256 so handshake testing
fails.
Otherwise the connection can stall due the indefinite delay of an explicit ACK,
for exapmle:
-> client sends the last Finished message
<- server sends the ACK, but the ACK is lost
-> client rentrasmit the Finished message
- server delay sending of the ACK until a fast timeout
-> client rentrasmit the Finished message quicker than the server timeout
- server resets the timeout, delaying sending the ACK
-> client rentrasmit the Finished...
Dlts13NewEpoch saves the keys currently derived in the ssl object.
Moving Dtls13NewEpoch inside DeriveTls13Keys avoid the risk of using the wrong
keys when creating a new Epoch.
This fixes at least he following scenario:
- Client has encryption epoch != 2 in the handshake (eg. due to rtx)
- Client derives traffic0 keys after receiving server Finished message
- Client set encryption epoch to 2 again to send the Finished message, this
override the traffic key computed
- Client creates the new epoch with the wrong key
Marco Oliverio
Juliusz Sosinowicz
Daniel Pouzzner
Reda Chouk
Tobias Frauenschläger
JacobBarthelmeh
David Garske
Sean Parkinson