How to build and enable TLS1.2 and 1.3 session resumption?

[yangyangliuli]

Version

5.6.3

Description

I want to enable TLS/DTLS 1.2 and 1,3 session resumption, could you provide CMD for me to test wolfssl example? Many thanks.

[dgarske]

Hi @yangyangliuli ,

You'd want to use session tickets for resumption on those. Use --enable-session-ticket or define HAVE_SESSION_TICKET.

Our example/client and example/server enable session resumption using -r. We also have some resumption examples in wolfssl-examples/tls:

https://github.com/wolfSSL/wolfssl-examples/blob/master/tls/client-tls13-resume.c
https://github.com/wolfSSL/wolfssl-examples/blob/master/tls/client-tls-resume.c

Thanks,
David Garske, wolfSSL

[yangyangliuli]

Hi,

Many thanks for your help, but I still have some questions. Could you help me analyze it? Thank you in advance.

1. I enabled dtls session resumption on both server and client sides, I saw the following log on the console:
   Does this mean that the session rsumption was successful?
2. If yes, why can't Wireshark see the handshake process? Does Wireshark not support parsing dtls1.3 now?
3. How should I configure the session ressumption timeout? I can see dtls1.2 session resumption timeout is 300s(5 minutes) by wireshark. But I can't see dtls1.3 timeout. Can you tell me how to configure the session resumption timeout on the server? Thank you very much.

azureuser@ServiceTest:~/newwolf/wolfssl$ ./examples/server/.libs/server -u -v 4 -l TLS_AES_256_GCM_SHA384 -p 8036 -b -r -i
SSL version is DTLSv1.3
SSL cipher suite is TLS_AES_256_GCM_SHA384
SSL curve name is SECP256R1
SSL version is DTLSv1.3
SSL cipher suite is TLS_AES_256_GCM_SHA384
SSL curve name is SECP256R1
SSL reused session

azureuser@ServiceTest:~/newwolf/wolfssl$ ./examples/client/client -u -v 4 -h localhost -p 8036 -r
SSL version is DTLSv1.3
SSL cipher suite is TLS_AES_256_GCM_SHA384
SSL curve name is SECP256R1
Session Ticket CB: ticketSz = 142, ctx = initial session
I hear you fa shizzle!
SSL version is DTLSv1.3
SSL cipher suite is TLS_AES_256_GCM_SHA384
SSL curve name is SECP256R1
SSL reused session
reused session id
Session Ticket CB: ticketSz = 142, ctx = resumed session
Server resume: I hear you fa shizzle

[dgarske]

Hi @yangyangliuli ,

1. Yes it used session ticket resumption. The logs show it clearly with "cox = resumed session".

2. It would surprise me if Wireshark had DTLS v1.3 support. Even if it did you would not be able to see anything except the client_hello and server_hello in clear, since everything after that is encrypted. We do have some TLS v1.3 examples for logging the secrets using a key log that Wireshark can use here: https://github.com/wolfSSL/wolfssl-examples/blob/master/tls/client-tls13.c#L52 This could be adopted for the DTLS v1.3 example.

3. The server controls the session ticket timeout. You can use the generic API at the WOLFSSL object or WOLFSSL_CTX level using: wolfSSL_CTX_set_timeout or wolfSSL_set_timeout. Or you can use the session ticket hint API: int wolfSSL_CTX_set_TicketHint(WOLFSSL_CTX* ctx, int hint) where hint is the number of seconds to allow using the ticket.

Thanks,
David Garske, wolfSSL

[yangyangliuli]

Hi，
Understood, many thanks. I have two questions.

1. Wirshark cannot display information about DTLS1.3, so how can I view the interaction information between server and client? How to enable debugging and data printing information on the server side? I only know --enable-debug. Are there any other ways to debug?
2. If I want to test my project DTLS1.3 session resumption 0-RTT to connect wolfssl example server.c, If build with--enable-session-ticket --enable-earlydata --enable-psk is ok? In addition, do I need additional API calls from server.c?

Thanks in advance.

[dgarske]

Hi @yangyangliuli ,

1. In TLS v1.3 and DTLS v1.3 all handshake messages after client/server hellos are encrypted. I would suggest enabling the key logging feature (see --enable-keylog-export) and using Wireshark. They recently made some progress on support for this (see https://gitlab.com/wireshark/wireshark/-/issues/18071). Another option is adding build options for SHOW_SECRET and WOLFSSL_DEBUG_TLS to get additional logging.

2. Have you tried it? I believe that use case is supported. @julek-wolfssl ?

Thanks,
David Garske, wolfSSL

[julek-wolfssl]

Hi @yangyangliuli,

regarding 0-RTT in DTLS 1.3, we have observed an issue where the client sends the early data with the first ClientHello message but not with the second ClientHello message. This is because we enable the cookie exchange by default with DTLS 1.3. You can disable the cookie exchange on the server side with wolfSSL_disable_hrr_cookie for testing but we encourage keeping the cookie exchange on. We are working on a fix for the client side to properly support early data with the cookie exchange.

Juliusz

[yangyangliuli]

Hi,
Today I am testing DTLS1.3 session resumption 0-RTT, If I enable server options are right?
azureuser@ServiceTest:~/newwolf/wolfssl$ ./examples/server/.libs/server -u -v 4 -p 8037 -b -r -i -0 -J n -x

[julek-wolfssl]

@yangyangliuli The minimal parameters to run early data are

./examples/server/server -v 4 -u -r -J n -0
./examples/client/client -v 4 -u -r -0

I also needed to make a modification to the server to show the early data message

diff --git a/examples/server/server.c b/examples/server/server.c
index 2e28a624e..33a6e4eaa 100644
--- a/examples/server/server.c
+++ b/examples/server/server.c
@@ -3358,7 +3358,7 @@ THREAD_RETURN WOLFSSL_THREAD server_test(void* args)
                     err = 0; /* reset error */
                     ret = wolfSSL_read_early_data(ssl, input, sizeof(input)-1,
                                                                           &len);
-                    if (ret != WOLFSSL_SUCCESS) {
+                    if (ret <= 0) {
                         err = SSL_get_error(ssl, 0);
                     #ifdef WOLFSSL_ASYNC_CRYPT
                         if (err == WC_PENDING_E) {

[yangyangliuli]

Understood， many thanks. But I have another question, when my client(not example) tried to connect server example(using DTLS1.3 version), When I tested DTLS1.3 session resumption without early data, I find an interesting thing.
If I turn off client all log, the module will not have session resumption and will have a full handshake every time.
If I enable client all log, the module will session resumption.
If I add the sleep(1) to my client, my client will session resumption.
Could you help explain why?
Thanks in advance.

result = wolfSSL_connect(pSSL);
if (result != WOLFSSL_SUCCESS)
{
err = wolfSSL_get_error(pSSL, 0);
}
else
{
#ifdef TLS_SESSION_RESUMPTION
gint32 peek_buffer=0;
sleep(1);
wolfSSL_peek(pSSL, &peek_buffer, 1);
.......

[julek-wolfssl]

Session resumption in DTLS 1.3 is done through tickets. Tickets in DTLS 1.3 are a post-handshake message. You need to wait for the NewSessionTicket message after the handshake and only after it is sent, you can resume a session. I assume that turning on logging or the sleep provides enough of a delay for that message to be sent by the server. Otherwise, you are resuming without a ticket.