Naveen,

Yes of course! Our official support channel is support [at] wolfssl [dot] com (which forwards to our zendesk domain) or you can reach us through zendesk directly at https://wolfssl.zendesk.com for best response times and so we can properly prioritize support by organization.

Thank you for the pcap. Notice how the connection starts out at packet 9 (roughly time 21.64 seconds since the first packet was captured). Notice how the certificate verify isn't sent until 34.859 time. So it took roughly 13.34 seconds from client hello to certificate verify, it could possibly be a timeout. Do you know what timeout is set to on the peer?

I do not believe this is a cipher suite mismatch out of the gate (the peer would have hung up after the client hello instead of proceeding through the rest of the handshake if it was an outright mismatch).

However this does appear to be doing mutual authentication since I see a cert from the client to the peer in packet 15. It could be one of the sides just doesn't have the right cert loaded to verify with.

Can you tell me if this is a test using two wolfSSL end-points or is only one side of this connection using wolfSSL? Was this one of our default examples from wolfssl-4.3.0/examples/ directory or a different test application? If it was one of our examples what command was used to test? Can I replicate the failure on my end?

Warm Regards,

K

Hi Haere,

I received a nearly identical inquiry this morning through our support channel and suspect this might be a duplicate inquiry but for others reading the forums I am copy/pasting my response to that Zendesk ticket that came in through support [at] wolfssl [dot] com:

Warm Regards,

K

ThePrintz,

You need to specify WOLFSSL_SHA3 also notice those are not sha512 or sha384 only those are sha3-384 and sha3-512. Sha3 is the final version NIST adopted based on Keccak which won the sha3 contest.

Warm Regards,

K

nelsongoncalves,

Can you try calling wc_EncodeSignature before doing the "sign" operation (like in this example https://github.com/wolfSSL/wolfssl-exam … st.c#L165) and let me know if that addresses the expected format issue?

Example:

   /* Add ASN digest info header */
   ret = wc_EncodeSignature(Digest_buf, Hash_buf, Hash_len, SHAh);
   printf("Digest Header: %d\n", ret);
   if (ret <= 0) { error handling };
   Digest_len = ret;

Warm Regards,

K

This was resolved by sending the ServerNameIndication (sni) extension. wolfSSL was configured with --enable-sni --enable-tls13. Using the same GlobalSign-Root-CA-R2.pem as was used in a successful TLS 1.2 connection without the SNI extension:

kalebhimes@kalebs-MBP clean-wolfssl % ./examples/client/client -h www.google.com -p 443 -v 4 -g -S www.google.com -A google-certs/GlobalSign-Root-CA-R2.pem 
SSL version is TLSv1.3
SSL cipher suite is TLS_AES_128_GCM_SHA256
SSL curve name is SECP256R1
SSL connect ok, sending GET...
HTTP/1.0 404 Not Found
Content-Type: text/html; charset=UTF-8
Referrer-Policy: no-referrer
Content-Length: 1571
Date: Fri, 
14 Feb 2020 18:19:11 GMT
Alt-Svc: quic=":443"; ma=2592000; v="46,43",h3-Q050=":443"; ma=2592000,h3-Q049=":443"; ma=2592000,h3-

- K

Believe this is the same question as: https://github.com/wolfSSL/wolfssl/issues/2794

- K

@ThaPrintz,

Thank you so much for reaching out with your questions.

Please try adding the settings to a custom user_settings.h and globally define WOLFSSL_USER_SETTINGS. At the application level you need to always include the <wolfssl/wolfcrypt/settings.h> before any other wolfSSL headers.

All other custom settings like user_settings.h should be included inside wolfssl/wolfcrypt/settings.h. user_settings.h is included in wolfssl/wolfcrypt/settings.h when WOLFSSL_USER_SETTINGS is defined globally.

Regards,

K

akhi_gangwar,

I fail to understand the need to do it this way, let me see if I understand your code correctly:

1) Global SSL variable.
2) Function start_TLS has an input parameter also an SSL variable
3) Function start_TLS has a second local parameter also an SSL variable.

We now have 3 SSL pointers, one global, one that was passed and one that was declared locally.

The logic seems to be:

4) Do setup and initialization with local variable. Assign local variable to passed variable. passed variable is global variable.

Why not just do:

setup and initialization with global variable?

There is no need for all this abstraction with 3 levels of separation.

Regards,

- K

akhi_gangwar,

This is what I suspected. The address is changing so what you are calling free on is not the original structure that was allocated.

Could you try changing the receiving function to expect a struct A** instead of a struct A* and then pass &A from the calling function? Let me know if the pointer values sync up after that!

Warm Regards,

K

@akhi_gangware,

One way to confirm you are freeing the global is to print the actual pointer value, you mentioned ssl is local and set to the global, when calling wolfSSL_new() try printing out the pointer value:

printf("ssl pointer = %p\n", ssl);

When freeing the global print the pointer value:

printf("global pointer = %p\n", ssl_cmd);

Are they the same memory location or are you freeing something other than what wolfSSL_new() got assigned to?

Regards,

K

@pbreed,

Let me know if I miss anything in the below:

So in your case 2 and 3...

Case 2 should return a WOLFSSL_SUCCESS because all the data was encrypted and handed off to the TCP stack. Once it's handed off to the TCP stack wolfSSL no longer has any control of it or knowledge of if only a partial send was achieved. wolfSSL is wholly disconnected from the transport medium, this is why we are able to provide custom I/O callbacks that work over any mode of transport and we are not limited to TCP only.

Case 3 is the only case above that should return a WANT_WRITE because only a partial encrypt was achieved and not all of the data was handed off to the TCP stack.

Yes absolutely. If you need the write callback to behave differently you could either modify the default one that expects TCP or you could write your own "send" function that says "if the sz passed in is larger than 16k (the limit of a TLS packet) only try to encrypt and send 16k at most, return the amount encrypted and written successfully. (which will be turned into a WANT_WRITE when it bubbles out).

Here is some basic documentation for the return codes and behavior that are expected from the I/O callbacks:

int myReceive(WOLFSSL *ssl, char *buf, int sz, void *ctx)
{
    // ssl = the current SSL object, cast to void if unused
    // buf = the buffer to receive the message, always used
    // sz = the size in bytes to receive, always used
    // ctx = a custom user context, can be anything, a structure, char buf, variable, cast to the correct type and use as needed, cast to void if unused.

    // RULE1: Only return the amount received.
    // RULE2: In the case of a failed receive return one of the following errors as appropriate, returning 0 will
    //        trigger an automatic re-receive attempt without returning control to the calling application.
    //        WOLFSSL_CBIO_ERR_GENERAL    = -1,     /* general unexpected err */           
    //        WOLFSSL_CBIO_ERR_WANT_READ  = -2,     /* need to call read  again */         
    //        WOLFSSL_CBIO_ERR_WANT_WRITE = -2,     /* need to call write again */         
    //        WOLFSSL_CBIO_ERR_CONN_RST   = -3,     /* connection reset */                 
    //        WOLFSSL_CBIO_ERR_ISR        = -4,     /* interrupt */                        
    //        WOLFSSL_CBIO_ERR_CONN_CLOSE = -5,     /* connection closed or epipe */       
    //        WOLFSSL_CBIO_ERR_TIMEOUT    = -6      /* socket timeout */ 
    // RULE3: In the case of a partial receive, only return the amount read, call wolfSSL_read again
    //        with the exact same parameters (including sz), the state machine will internally keep
    //        track of received vs remainder and will handle the remainder appropriately.
}

int mySend(WOLFSSL *ssl, char *buf, int sz, void *ctx)
{
    // ssl = the current SSL object, cast to void if unused
    // buf = the message to send, always used
    // sz = the size in bytes to send, always used
    // ctx = a custom user context, can be anything, a structure, char buf, variable, cast to the correct type and use as needed, cast to void if unused.

    // RULE1: Only return the amount sent.
    // RULE2: In the case of a failed send return one of the following errors as appropriate, returning 0 will
    //        trigger an automatic re-send attempt without returning control to the calling application.
    //        WOLFSSL_CBIO_ERR_GENERAL    = -1,     /* general unexpected err */           
    //        WOLFSSL_CBIO_ERR_WANT_READ  = -2,     /* need to call read  again */         
    //        WOLFSSL_CBIO_ERR_WANT_WRITE = -2,     /* need to call write again */         
    //        WOLFSSL_CBIO_ERR_CONN_RST   = -3,     /* connection reset */                 
    //        WOLFSSL_CBIO_ERR_ISR        = -4,     /* interrupt */                        
    //        WOLFSSL_CBIO_ERR_CONN_CLOSE = -5,     /* connection closed or epipe */       
    //        WOLFSSL_CBIO_ERR_TIMEOUT    = -6      /* socket timeout */ 
    // RULE3: In the case of a partial send, only return the amount written, call wolfSSL_write again
    //        with the exact same parameters (including sz), the state machine will internally keep
    //        track of send vs remainder and will handle the remainder appropriately.
}

    // Register your callbacks in place of the defaults:
    wolfSSL_CTX_SetIORecv(ctx, mySend);
    wolfSSL_CTX_SetIOSend(ctx, myReceive);

Let me know if this helps.

Warm Regards,

K

akhi_gangwar,

wolfSSL does not control the TCP/IP stack if that is what you are asking, wolfSSL would not block, prevent or limit calls to socket creation. In fact wolfSSL does not even depend on sockets, our library is abstracted with custom I/O callbacks so if a user wanted they could do a handshake over USB serial through UART, over bluetooth, in memory using buffers, or using any other forms of I/O that is available.

I am not sure why you are seeing this behavior but I can, with confidence, state that wolfSSL is not causing it directly. Is there a fixed memory requirement to open the socket? Are you at the limits of your run time resources when creating the socket? What does the socket libraries documentation say about it?

Warm Regards,

K