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
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
Juliusz Sosinowicz
rizlik
Reda Chouk
JacobBarthelmeh
Daniel Pouzzner
David Garske