Hello Yulia,

Can you tell us a bit about what is driving this effort?

From a high level lets' dig into one of your notes:

WHERE in the second fragment are the garbage values? Are they at the head or the tail of the message?

If they are at the HEAD don't forget the first 5-bytes of any TLS packet are the header denoting what kind of message (a handshake message in this case), the protocol version (TLS 1.3 in this case) and the length of the packet to follow (up to 16k). You'll need to change the length value to reflect the remainder that wasn't sent in the first fragment.

If the garbage values are at the TAIL of the message that might mean you didn't XMEMSET the transmit buffer before copying in the remainder. IE if you copied 16Kb in for the first fragment and the remainder is only 2Kb lets' say, and you just copy it in without clearing the first fragment you'll just be updating the first 2Kb and the final 14Kb will be from the first fragment if that makes sense.

Hope this helps get you on the right track, let me know if you have any followup questions.

- KH

@Vitus,

One thing I noted, you are building on windows which does not support <wolfssl/options.h>. <wolfssl/options.h> is for use on *NIX systems where the ./configure script was run and options.h was auto-generated.

On windows please replace all occurrances of <wolfssl/options.h> with:

#include <wolfssl/wolfcrypt/settings.h>
#ifndef WOLFSSL_USER_SETTINGS
    #error "Sanity Check: Please add the PreProcessor setting WOLFSSL_USER_SETTINGS to the project"
#endif

If the above sanity check is seen please right-click on the project in the solution explorer window and open "Properties" ->C/C++ -> "Preprocessor" -> "Preprocessor Definitions" and add "WOLFSSL_USER_SETTINGS" to the project pre-processor settings. (See attached screen shot 1)

If you then get an error about "user_settings.h" not being found go to "Properties" ->C/C++ -> "General" -> "Additional Include Directories" and add a path to "C:\path-to-wolfssl-root\IDE\WIN" where the windows user_settings.h header resides. (See attached screen shot 2)

Warm Regards,

K

Scotty,

Understood. Also be aware that in the selection process the certs are part of the decision. If the server has both an ECC cert chain and an RSA cert chain it should be able to connect with either ECDHE_RSA or ECDHE_ECDSA. If the server has algorithmic support for ECC but only has RSA certificates it will only be able to negotiate ECDHE_RSA.

Yes a good test would be to limit the client ciphers to only one at a time and then test if each connects. If the client only presents a single option to the peer the peer will either have to select that option or tell the client it can't negotiate that option (by severing the connection). In this way you can determine what all would be supported, as I mentioned the only control the client has over the selection process is in what it presents to the server.

You can present a single cipher with:

wolfSSL_CTX_set_cipher_list(ctx, "ECDHE-ECDSA-AES128-SHA");

OR

You can present two or more with a colon delimited list:

char cipherList[] = "ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA256";
wolfSSL_CTX_set_cipher_list(ctx, cipherList);

OR

You can not use that API at all and wolfSSL will always send a list of all ciphers supported by the current build configuration.

Warm Regards,

K

Scotty2541,

The server ALWAYS gets to pick what it prefers based on what the client sends. The client only has contol in that it can LIMIT the options available to the server to pick from.

The order in which they arrive does not matter. The server is configured how it is configured.

In MOST cases a server will try to pick the STRONGEST cryptographic option but some might be configured to consider run-time resource requirements or some other governing factor in the decision making process for which cipher it selects from the client offered list.

Warm Regards,

- K

Checking if an internal example exists, will get back to you shortly!

- KH

Hi Octopus01,

Thanks so much for your question. Can you compare your setup to our very simple example at the below link to see if there are any differences?

https://github.com/wolfSSL/wolfssl-exam … rver-tls.c

Also I would suggest double-checking the scope of the structures, when configuring a WOLFSSL_CTX in a function a typical flow would be like below.

int functionA(WOLFSSL_CTX* ctx) {
   // configure context
   // return success/fail code
}

int functionB(WOLFSSL* ssl) {
    // configure ssl object
    // return success/fail code
}

void functionMain(void)
{
    WOLFSSL_CTX* ctx;
    WOLFSSL* ssl;
    int return_code;

    return_code = functionA(ctx);
    return_code = functionB(ssl);
}

Warm Regards,

K

Thomas,

Thank you so much for your questions. There is no patch for the mentioned attributes at the moment. We can address it in one of two ways.

One, we can take this down as a feature request. We work on feature requests internally between other funded projects so there isn't a timeline guarantee on any new features unless a customer decides to fund the effort for a guaranteed implementation timeline.

Two, as you suggested you can make the changes yourself and submit those changes as a pull request against https://github.com/wolfssl/wolfssl.git.

In order to accept changes from individuals that are not employees of wolfSSL we have to work through some legal paperwork to get you set up as an approved contributor under the wolfSSL Incorporated organization. To start that process go ahead and open your pull request when ready and then send an email to "support [at] wolfssl [dot] com" with the subject line referencing the pull request number and request a contributor agreement to go over with your own legal department before returning a signed copy to wolfSSL for review by our legal department.

If your contributor status is approved we can then begin reviewing the proposed changes for acceptance and ultimately merging into the wolfSSL master code branch.

Warmest Regards,

K

@srihari,

wolfMQTT uses wolfSSL_write. wolfSSL_write ultimately uses the default custom callback for sending (EmbedSend()) which is found in wolfssl-root/src/wolfio.c. wolfSSL uses a custom I/O callback solution allowing our users to over-ride the default if necessary (for more on this checkout https://www.wolfssl.com/wolfssl-alterna … support/).

Warm Regards,

K

@remix,

Try adding dash capitol c (-C) to disable the requirement to load a certificate revocation list. Let us know if this resolves the CRL check failing.

Warm Regards,

K

Hi Tagazop,

Thank you for reaching out. Can you tell us a bit about your project and end goals? We are always eager to hear about the new ways in which wolfSSL is being used.

To turn on features not enabled by default please checkout the wolfSSL manual https://www.wolfssl.com/documentation/w … Manual.pdf Chapter 2, section 2.4.4 Enabling Features Disabled by Default.

The only one not documented (because it is considered unsafe for use) is ECB mode, please check the source file in wolfssl/wolfcrypt/src/aes.c for the option to turn on "direct" encryption.

Warm Regards,

KH

Typically a front end serving the proxy will have a server name indication to direct traffic to the proxy. You can specify a server name indication with the client by configure with --enable-sni and setting parameter -S <target server name>

- KH

karanbanthia,

Are you using the USE_FAST_MATH setting? If so you should configure more stack, try around 23k and make sure you have ALT_ECC_SIZE defined when USE_FAST_MATH is also defined.

Heap you should only need 16-30k depending on optimizations. If you don't want to set the stack higher you can try using the setting WOLFSSL_SMALL_STACK to shift memory usage to the HEAP and remove the setting USE_FAST_MATH and compile integer.c instead of tfm.c to use mostly HEAP.

- KH