Hi cxdinter,

tcp_connect is the client side API for connecting to a server. To connect to the server you need to know which port the server is listening on for the protocol you intend to connect with thus the argument "port" in the API call to tcp_connect.

So for example if you were to use wolfTLSv1_2_client_method and pass in port 22 to tls_connect then you would be attempting to connect to a port on the server that supports SSH and not TLS. I would expect this to fail. If however you were to change that port number to 443, the standard port for secure http (HTTPS), I would expect this to work as long as the client and server were able to agree on a common cipher suite and the server and client both supported TLS v1.2.

Does that clear things up a bit? Client will be using an ephemeral (randomly assigned) port to send messages out from your computer. The call to tls_connect requires a port argument to know the destination port those messages will be sent to on the server. Without specifying a destination port the packets would never arrive at their intended destination.

Warm Regards,

Kaleb

Hi cxdinter,

OK, you are on the client side.

I will try to clarify a bit more. When a client makes a connection to a server you don't ever assign a specific port to the client, it is assigned randomly when you create your socket (ephemeral port assignment). So you would have to create two unique sockets for the two tunnels.

The server identifies a client uniquely by a tuple. The tuple will contain the random port it was assigned. The server can differentiate between the two connections based on the tuple. So you would call connect twice as the requirement states, once per socket, and then upgrade one of the two connections to a websocket. The requirement does not mention that SNI is part of the differentiation so I think it is safe to assume it already knows how to handle this setup. The server should handle forwarding the websocket connection packets to the websocket service and the non-websocket packets to the non-websocket service.

Regards,

Kaleb

Hi cxdinter,

The way this is accomplished is by calling wolfSSL_get_session on the ssl object. This will return a WOLFSSL_SESSION* effectively  saving the session. Then the next time you need to resume a session you would call wolfSSL_set_session with the ssl object and the saved session to resume the session. If an error code is returned that would serve as the validity check you mentioned.

The API's are:

/* returns a WOLFSSL_SESSION object on sucess or NULL on failure */
WOLFSSL_SESSION* wolfSSL_get_session(WOLFSSL* ssl);

/* returns SSL_SUCESS on success or SSL_FAILURE on failure */
int wolfSSL_set_session(WOLFSSL* ssl, WOLFSSL_SESSION* session);

Those API's wrap the internal API's "GetSession" and "SetSession" that are not exposed for external linking. Example code to look at would be in <wolfssl-root>/src/internal.c, the function "ProcessOldClientHello". When we are doing a resume session internally we use the internal API's "GetSession" and "SetSession", you would use a similar process but call the API wrapper functions "wolfSSL_get_session" and "wolfSSL_set_session" instead.

Let us know if you have any other questions!

Warm Regards,

Kaleb

Hi Peter,

Please see the note in README on CyaSSL Release 2.9.4 "-PIC32 MZ hardware support". It looks like this update was never added to the manual. I have made a note of it and we will try to get that section in the next Manual update.

The harmony configurator is not for configuring third party libraries, it is used to enable/disable features / support on the target platform in an automated fashion. Occasionally it will name things differently then if manually created: for example instead of "UART_WriteBuffer" the code configurator might call it "UART1_WriteBuffer" which would be incompatible with "out of the box". So there may be some customization required when using the code-configurator.

Have you had a chance to go over the README for WOLFSSL_MICROCHIP_PIC32MZ crypto engine support? <wolfssl-root>/mplabx/README. Specifically note:

Please take a moment to build our pre-existing examples and get a feel for the setup. If you have any questions on those examples please let us know!

Regards,

Kaleb

Hi will,

No problem, thank you for using the wolfSSL forums. I'm so happy we were able to assist in this matter!

- Kaleb

Hi borodatiyPupok,

The image you sent shows the static lib only. To see the true size of an application could you try compiling the application that will statically link to wolfssl.lib and check the resulting size of the app? The static lib will contain many portions of code that will get optimized out in an executable. Also I suspect you may be building one of the Debug builds with the size you are seeing. In MSVS go to "Build->Configuration Manager...-> set wolfssl to "Release" ".

To illustrate I'll include the build sizes I see with DEBUG and RELEASE builds and also compare the lib size to the executable size:

DEBUG BUILD for x64:

-rwx------+ 1 boz_windows None  839680 Oct 24 08:19 testsuite.exe
-rwx------+ 1 boz_windows None  608332 Oct 24 08:19 testsuite.ilk
-rwx------+ 1 boz_windows None 1338368 Oct 24 08:19 testsuite.pdb
-rwx------+ 1 boz_windows None 1940904 Oct 24 08:19 wolfssl.lib

lib           = 1,940,904 (nearly 2 Mb)
testsuite.exe = 839,680    (839K)

NOTE: The .lib is much larger than testsuite.exe but testsuite.exe is compiled with the static library. You can see much of the code was optimized out for testsuite.exe

RELEASE BUILD for x64:

-rwx------+ 1 boz_windows None  390144 Nov 14 12:46 testsuite.exe
-rwx------+ 1 boz_windows None  969728 Nov 14 12:46 testsuite.pdb
-rwx------+ 1 boz_windows None 3346028 Nov 14 12:46 wolfssl.lib

lib           = 3,346,028 (3.3 Mb)
testsuite.exe = 390,144    (390K)

Even though the .lib is larger in release mode you can see the executable is far more optimized (839k to 390k) so the size was reduced by more than half. I did these tests with the default configure settings of the windows project. Please try comparing the same with your configure settings and let me know the results.

Hi will,

pthreads or POSIX threads are provided in BSD library (Unix / Linux). How did you build the library and are you on a Unix/Linux system or windows?

UNIX/LINUX:
If you are on Unix/Linux please also include <wolfssl/options.h> so you get the same settings as wolfSSL was built with.
If that doesn't resolve the issue then please got to wolfssl directory and re-run ./configure <your settings> && make check && make install (or sudo make install if using default install location).

WINDOWS:
If you are on windows you would need to include both "user_settings.h" (or if it cannot locate by default "IDE/WIN/user_settings.h") and <wolfssl/wolfcrypt/settings.h> in your project.

Kind Regards,

Kaleb

Hi wieslaws,

Is this code with a custom IO callback or some other function. I can say that in the case of a SSL_ERROR_WANT_READ that value should continue to try as the connect did succeed with SSL_SUCCESS but there is no data on the socket to be read.

Option 1: if you don't mind using a blocking implementation, it appears you may already have that code in a loop due to the "break;" calls I see. You could change those "break;" calls to "continue;" in the case of SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE, and only call "break;" if some other error occurs.

Option 2: if you're after a non-blocking solution you could create custom IO callbacks and register them with:

     wolfSSL_SetIORecv(<wolfSSL ctx>, <your custom receive function here>);                                           
     wolfSSL_SetIOSend(<wolfSSL ctx>, <your custom send function here>);

Then make sure to set the SSL Object nonblocking with:

     wolfSSL_set_fd(<ssl object>, <socket>);                                               
     wolfSSL_set_using_nonblock(<ssl object>, <socket>);

Then you could return WOLFSSL_CBIO_ERR_WANT_READ or WOLFSSL_CBIO_ERROR_WANT_WRITE and wolfSSL could keep re-trying the read until it succeeded or some other error code was returned.

Regards,

Kaleb

Hi borodatiyPupok,

Just one question before suggesting configuration settings. Do you need TLS/SSL, are you building a networked application or do you purely only need RSA key gen and RSA encrypt/decrypt? Are you expecting any other functionality whatsoever?

20 Kb is PSK only, and would be very difficult to achieve with public key algorithms. To get < 200Kb we'll have to determine your use case IE answers to the above question.

Kind Regards,

Kaleb

Hi jellefresen,

pthreads is not something provided by wolfSSL. Pthreads stands for POSIX threads and is typically only supported in a POSIX environment.

Please see instructions on building for ARDUINO here: https://github.com/wolfSSL/wolfssl/blob … /README.md

One crucial step is to uncomment the define for WOLFSSL_ARDUINO in <wolfssl-root>/wolfssl/wolfcrypt/settings.h. This will in turn define SINGLE_THREADED which prevents our libraries from including the pthreads header file.

Regards,

Kaleb

Hi will,

This error code is only ever returned in wc_ChaCha20Poly1305_Decrypt API. It looks like you agreed on a chacha20 poly1305 cipher suite and got a decrypt error.

Could you tell us which certificate you loaded and which "Apple site" you are connecting to so we can try to re-produce the issue?

My first suspicion is that perhaps you loaded an RSA certificate and connected with an ECC based cipher or vise versa, but it's hard to tell with so few details. Please provide the requested info and we'll try to help you with your issue.

Kind Regards,

Kaleb