This free is redundant in most cases but it covers the specific
case of using async, exiting SendServerKeyExchange early due to
WANT_WRITE or WC_PENDING_E, then later freeing the async context
without calling SendServerKeyExchange again.
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...
Do not consider the handshake finished until the last server ACK.
This way the application knows where to switch from
wolfSSL_negotiate/wolfSSL_connect to wolfSSL_read/wolfSSL_write.
- random.c: use getrandom when available and fall back to direct file access
- openssh.yml: run more tests
- openssh.yml: add 10.0p2 and 9.9p2
- configure.ac: detect if `getrandom` is available on the system
- configure.ac: openssh requires WC_RNG_SEED_CB to always use `getrandom` so that the RNG doesn't get killed by SECCOMP
It is possible that the client will provied `trusted_ca_keys` during a
TLSv1.3 connection with 1.2 downgrade. wolfSSL would error with
`EXT_NOT_ALLOWED`. The TLSv1.3 spec states that it can be provided and
should be ignored.
ZD 19936
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
Allow backward compatibilitly of Hybrid ML_KEM codepoints in TLS with
version before wolfSSL 5.8.0.
When WOLFSSL_ML_KEM_USE_OLD_IDS is defined, it will accept the old
codepoints for P256 with ML-KEM-512, P384 with ML-KEM-768, P521 with
ML-KEM-10124. (Others combinations were not know pre 5.8.0.)
Both old client with new server and new client with new server work with
old codepoints.
Server only uses curves that are supported by both the client and the server. If no common groups are found, the connection will fail in TLS 1.2 and below. In TLS 1.3, HRR may still be used to resolve the group mismatch.
