This way we can use wolfSSL_Peek() invoked with sz == 0 to process pending
records and, if none of this records is an application data record, we will not
block.
Introduce ACK and retransmission logic, encapsulated in a Dtls13RtxFsm
object. The retransmission or the sending of an ACK is scheduled by setting the
appropriate flag inside the Dtls13RtxFSM object but the actual writing on the
socket is deferred and done in wolfSSL_Accept/Connect.
* Retransmission
Each sent message is encapsulated in a Dtl13RtxRecord and saved on a list. If we
receive an ACK for at record, we remove it from the list so it will be not
retransmitted further, then we will retransmit the remaining
ones. Retransmission is throttled: beside link congestion, this also avoid too
many sequence numbers bounded with a record.
* ACK
For each received record we save the record sequence number, so we can send an
ACK if needed. We send an ACK either if explicitly needed by the flight or if we
detect a disruption.
Co-authored-by: Juliusz Sosinowicz <juliusz@wolfssl.com>
This commit implements the core of the header parsing, building, and the sending
and receiving routines that handle fragmentation and defragmentation.
* In DTLSv1.3 the header used for protected messages is a variable-length header,
and it is described RFC9147 Section 4.
* Fragmentation happens after building the full message, if necessary. If the
underlying I/O can't send a fragment because of a WANT_WRITE error, the sending
of fragments will continue in the next invocation of
wolfSSL_connect/wolfSSL_accept/wolfSSL_write. In this case the message is saved
in a buffer inside the WolfSSL object.
* Defragmentation works like DTLSv1.2 defragmentation, and re-use
most of the same code.
* The Dtls13AddHeaders() function does not add the record layer header, but it
lefts space for it. It is eventually placed by BuildTls13Message() to allow
easier management of sequence numbers.
In DTLSv1.3, because of retransmission and reordering, we may need to encrypt or
decrypt records with older keys. As an example, if the server finished message
is lost, the server will need to retransmit that message using handshake traffic
keys, even if he already used the traffic0 ones (as, for example, to send
NewSessionTicket just after the finished message).
This commit implements a way to save the key bound to a DTLS epoch and setting
the right key/epoch when needed.
- Fix case where message grouping can make CheckAvailableSize return a WANT_WRITE
- CheckAvailableSize in tls13.c will not return a WANT_WRITE since it only does so for DTLS <=1.2
Testing:
./autogen.sh
./configure --enable-psk
make all check
$ ./examples/server/server -j -l ECDHE-PSK-AES128-GCM-SHA256
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
SSL curve name is SECP256R1
Client message: hello wolfssl!
$ ./examples/client/client -s -l ECDHE-PSK-AES128-GCM-SHA256
SSL version is TLSv1.2
SSL cipher suite is TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256
SSL curve name is SECP256R1
I hear you fa shizzle!
- Async I/O can be turned off with WOLFSSL_NO_ASYNC_IO
- WOLFSSL_ASYNC_IO functionality enabled in SendCertificateVerify() and SendServerKeyExchange() to allow safe re-entry into SendHandshakeMsg()
- Testing size of structs is refactored int WOLFSSL_ASSERT_SIZEOF_GE()
