DTLS: Add server side stateless and CID QoL API #8224

julek-wolfssl · 2024-11-25T17:33:11Z

wolfDTLS_accept_stateless - statelessly listen for incoming connections
wolfSSL_inject - insert data into WOLFSSL object
wolfSSL_SSL(Enable|Disable)Read - enable/disable reading from IO
wolfSSL_get_wfd - get the write side file descriptor
wolfSSL_dtls_set_pending_peer - set the pending peer that will be upgraded to regular peer when we successfully de-protect a DTLS record
wolfSSL_dtls_get0_peer - zero copy access to the peer address
wolfSSL_is_stateful - boolean to check if we have entered stateful processing
wolfSSL_dtls_cid_get0_rx - zero copy access to the rx cid
wolfSSL_dtls_cid_get0_tx - zero copy access to the tx cid
wolfSSL_dtls_cid_parse - extract cid from a datagram/message

- wolfDTLS_accept_stateless - statelessly listen for incoming connections - wolfSSL_inject - insert data into WOLFSSL object - wolfSSL_SSL(Enable|Disable)Read - enable/disable reading from IO - wolfSSL_get_wfd - get the write side file descriptor - wolfSSL_dtls_set_pending_peer - set the pending peer that will be upgraded to regular peer when we successfully de-protect a DTLS record - wolfSSL_dtls_get0_peer - zero copy access to the peer address - wolfSSL_is_stateful - boolean to check if we have entered stateful processing - wolfSSL_dtls_cid_get0_rx - zero copy access to the rx cid - wolfSSL_dtls_cid_get0_tx - zero copy access to the tx cid - wolfSSL_dtls_cid_parse - extract cid from a datagram/message

rizlik

I think this is a big step in the right direction but there are things unclear. These comments are considering wolfSSL/wolfssl-examples#472 as the user of the changes in this PR.

what's the purpose of splitting the fd in write and read?
I don't get why we should use the pendingPeer and the example doesn't use it. It looks complicate and there is code that get hit after we copy the pendingPeer to the current Peer that it doesn't look doing nothing other than flipping the processPendingRecord bit.
I don't see much gain in using wolfSSL_accept_stateless.
AFAIU it just boils down in a) disabling read so that it can return before reading from the socket and b) to return after a good CH. a) avoids dropping other peer messages that can be received in the EmbedRecvFrom. But, as shown in the example, the server has already to read the messages itself outside of the wolfSSL to do proper demux. I wonder if then this is superfluous.

I would suggest of using a custom internal field like the pendingPeer, but called, as you suggested, currentRecordPeer.
Until the ssl is stateless, this is set on recvfrom, but no filtering happens bc of this.
It's used as the destination of the HRR/HVR and to compute the cookie.
It's not used anywhere else and it's not automatically copied over the other peer.
This way an ssl object can be used to reply to the CHs w/o cookies.
If we got a CH w/ valid cookie we can then leverage our existing goodch callback to set the right peer for sending and continue the connection.
If the application wants to demux, it needs to manage the reading from the socket itself anyway.

Just to recap, my suggestion are:

In EmbedRecvFrom to set a "peer to send the HRR/HRV" to if we are in a stateless
Application needs to use ChGoodCB to set the proper peer (is it already like this?)
Make clear that application needs to manage the read itself if it wants to demux over a single socket

The new APIs (inject, parse_cid) allows the application to manage the connection with a good tradeoff of complexity and control imo.

rizlik · 2024-11-26T09:24:49Z

doc/dox_comments/header_files/ssl.h

+/*!
+    \ingroup IO
+
+    \brief


missing doc

rizlik · 2024-11-26T09:26:18Z

doc/dox_comments/header_files/ssl.h

+\brief Get the ConnectionID used by the other peer. See RFC 9146 and RFC
+9147.
+
+ \return WOLFSSL_SUCCESS if ConnectionID was correctly copied, error code


ConnectionID is not copied.

rizlik · 2024-11-26T09:31:56Z

src/dtls.c

+        if (msgSz < DTLS_RECORD_HEADER_SZ + cidSz)
+            return;
+        /* content type(1) + version(2) + epoch(2) + sequence(6) */
+        *cid = msg + ENUM_LEN + VERSION_SZ + OPAQUE16_LEN + OPAQUE16_LEN +
+                OPAQUE32_LEN;


why the calculation of lengths are different between the check and the parsing?

rizlik · 2024-11-26T09:38:50Z

src/ssl.c

-        int result = DtlsMsgPoolSend(ssl, 0);
+        int result;
+#ifdef WOLFSSL_DTLS13
+        if (IsAtLeastTLSv1_3(ssl->version))


Is this change related to the feature or is a general fix?

rizlik · 2024-11-27T08:33:08Z

src/ssl.c

+
+    if (ssl->buffers.dtlsCtx.peer.sa != NULL &&
+            ssl->buffers.dtlsCtx.peer.sz == peerSz &&
+            XMEMCMP(ssl->buffers.dtlsCtx.peer.sa, peer, peerSz) == 0) {


This is not the correct way to compare sockaddr structure, see sockAddrEqual

rizlik · 2024-11-27T08:41:49Z

src/internal.c

        if (ssl->buffers.inputBuffer.length - *inOutIdx <
                (word32)cidSz + LENGTH_SZ)
            return LENGTH_ERROR;
-        if (cidSz > DTLS_CID_MAX_SIZE ||
-                wolfSSL_dtls_cid_get_rx(ssl, cid, cidSz) != WOLFSSL_SUCCESS)
+        if (cidSz != DtlsGetCidRxSize(ssl) ||


is this check redundant? we set cidSz to DtlsGetCidRxSize() before

rizlik · 2024-11-27T09:11:55Z

src/ssl.c

+
+    WOLFSSL_ENTER("wolfSSL_read_internal");
+
+    if (ssl == NULL || data == NULL || sz <= 0)


should we allow sz == 0?

rizlik · 2024-11-27T09:40:30Z

src/dtls.c

 int wolfSSL_dtls_cid_max_size(void)
 {
    return DTLS_CID_MAX_SIZE;
 }
+
+void wolfSSL_dtls_cid_parse(const unsigned char* msg, unsigned int msgSz,


return WOLFSSL_SUCCESS or WOLFSSL_FAILURE.

rizlik · 2024-11-27T10:25:15Z

doc/dox_comments/header_files/ssl.h

+    \sa wolfSSL_dtls_set_peer
+    \sa wolfSSL_dtls
+*/
+int  wolfSSL_dtls_get0_peer(WOLFSSL* ssl, const void** peer, unsigned int* peerSz);


don't expose the internal cid.
Prefer to add an API to compare to the ssl cid object if afraid of performance loss of copying the cid.
(like wolfSSL_dtls_cid_cmp(WOLFSSL*ssl,byte *cid, int cidSz))

julek-wolfssl self-assigned this Nov 25, 2024

julek-wolfssl requested a review from rizlik November 25, 2024 17:33

julek-wolfssl force-pushed the dtls-server-demux branch from 023cc55 to 86376db Compare November 26, 2024 08:55

julek-wolfssl mentioned this pull request Nov 26, 2024

DTLS: Add server single socket demultiplexing example wolfSSL/wolfssl-examples#472

Open

julek-wolfssl force-pushed the dtls-server-demux branch 3 times, most recently from 9b95077 to baa7738 Compare November 26, 2024 14:22

rizlik reviewed Nov 27, 2024

View reviewed changes

Client TLS: Set traffic decrypt keys when parsing Finished

935227a

julek-wolfssl force-pushed the dtls-server-demux branch from baa7738 to 935227a Compare November 27, 2024 12:11

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

DTLS: Add server side stateless and CID QoL API #8224

DTLS: Add server side stateless and CID QoL API #8224

julek-wolfssl commented Nov 25, 2024

rizlik left a comment •

edited

Loading

rizlik Nov 26, 2024

rizlik Nov 26, 2024

rizlik Nov 26, 2024

rizlik Nov 26, 2024

rizlik Nov 27, 2024

rizlik Nov 27, 2024

rizlik Nov 27, 2024

rizlik Nov 27, 2024

rizlik Nov 27, 2024


		WOLFSSL_ENTER("wolfSSL_read_internal");

		if (ssl == NULL \|\| data == NULL \|\| sz <= 0)

DTLS: Add server side stateless and CID QoL API #8224

Are you sure you want to change the base?

DTLS: Add server side stateless and CID QoL API #8224

Conversation

julek-wolfssl commented Nov 25, 2024

rizlik left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rizlik left a comment •

edited

Loading