Hi he1n,

Can you try adding these macros to the build:

-DWOLFSSL_TLS13
-DHAVE_TLS_EXTENSIONS
-DHAVE_SUPPORTED_CURVES
-DHAVE_ECC
-DHAVE_HKDF
-DHAVE_FFDHE_8192
-DWC_RSA_PSS

If those don't solve it I will ask our android expert to take a look!

Warm Regards,

K

Carlo,

Thank you for your notes. As I mentioned in my reply on https://www.wolfssl.com/forums/topic156 … shake.html One can not manage read/writes during the handshake. The internal state machine will manage it based on the RFC specs. Only once the handshake has completed and the connection is established can the end-application then take over and manage reads/writes separately.

Warm Regards,

K

akhi_gangwar,

We have checked the following so far:

1) Crypto tests are all passing (crypto operating normally)
2) cert/key work in another test (assuming they are in fact being used in mutual auth in that test)
3) you are confirming they are a pair just to be sure.

The next things that could lead to a reset are:

1) A collision between heap and stack, double check the device has sufficient memory allocated for the task expecially if using USE_FAST_MATH which requires more stack than heap or change to using integer.c instead of tfm.c and remove the USE_FAST_MATH settings.

2) A mismatch in settings between app and library can lead to undefined behavior. When using user_settings.h make sure the pre-processor macros at the project level include the define WOLFSSL_USER_SETTINGS and that your application includes the header <wolfssl/wolfcrypt/settings.h> BEFORE ALL OTHER wolfSSL headers and is pulling in user_settings.h.

Warm Regards,

K

Here is the key (can only attach one file at a time)

- K

laurensiaaverin,

You do need to link the ntru crypto from github. wolfSSL has API's that rely on the ntru crypto library but make it easier for users to consume.

Warm Regards,

K

Waigor,

This is technically a "both server and client" issue.

- The client (browser) is to blame for requesting to resume a session rather than doing a full handshake.

- The server is to blame because it allows the client to resume old sessions instead of doing a new handshake. When session caching is enabled, clients are allowed to resume sessions up until that session has expired based on the session timeout or until the session cache becomes so full that older sessions get replaced by newer sessions and then clients attempting to resume those older sessions have to perform a full handshake.

This can be changed by disabling session resumption on the server side (but can lead to decreased performance as a result). There may also be a way to disable session resumptions in chrome and firefox to get the same behavior as IE11 but I am not familiar with how to do that.

Warm Regards,

K

carlo,

Thanks for your noted concerns. Due to the embedded design of the library we have a single I/O buffer. Since TLS packets can be anywhere from a few kilobytes up to 16kb we did not want to force users in constrained environments to have to set aside 32kb for reading and writing by default.

Since there is only one buffer for I/O this means that calls to wolfSSL_read() and wolfSSL_write must be mutex protected to avoid read and write calls stomping on eachother. One may not assume read/write separation until post handshake. (This is covered in the wolfSSL manual chapter 9 on "Thread Safety" https://www.wolfssl.com/docs/wolfssl-manual/ch9/)

Once the handshake is completed if there is a desire to handle reading and writing from separate threads we offer a feature called "write duplicate" so that users can make a COPY of the SSL_OBJECT and use the copy only for writing and the original only for reading.

We provide an example of setting up a duplicate SSL object here: https://github.com/wolfSSL/wolfssl-exam … writedup.c

Please let us know if this helps with the above concerns!

Warm Regards,

K

Hi carlo,

Think of them this way:
WOLFSSL_CTX = a FACTORY Context for spawning SSL Objects of the same type (one can setup multiple factories)
WOLFSSL = an SSL OBJECT used to establish a single session between a client and server.
WOLFSSL_SESSION = information about a specific session that can be used to resume after an unexpected shutdown.

Let me know if this helps with the naming scheme.

Warm Regards,

K

@carlo,

Thank you so much for your followup. The maintainer I mentioned above has since departed wolfSSL Inc and it looks like the action item was never completed. I just opened a PR for it here: https://github.com/wolfSSL/wolfssl/pull/3066

To avoid unwanted protocol versions it's as easy as turning them off. If you don't want to risk negotiating older protocols please use --disable-oldtls to turn off TLSv1.1, TLSv1.0 and SSL3.0.

./configure --disable-oldtls --disable-tlsv12 # Supports TLSv1.3
./configure --disable-oldtls                  # Supports TLSv1.3 and TLSv1.2
./configure --disable-sslv3 --disable-tlsv10  # Supports TLSv1.3, TLSv1.2 and TLSv1.1
./configure --disable-sslv3                   # Supports TLSv1.3, TLSv1.2, TLSv1.1 and TLSv1.0
./configure --enable-oldtls                   # Supports TLSv1.3, TLSv1.2, TLSv1.1, TLSv1.0, and SSLv3.0

NOTE: This is for v4.4.1 and newer of wolfSSL. For version 4.4.0 and older tls1.3 was not enabled by default and you would need to add --enable-tls13 to the configure options to enable TLSv1.3 support.

... etc.

Use combinations of options to specify what is supported and the wolfSSLv23_server_method() or wolfSSLv23_client_method() will negotiate what it can based on what is enabled!

Cheers,

KH

Hi jijo7thomas,

As the error indicates it would seem the wrong version or a non-supported version was used. Do you know which SSH version was sent?

Warm Regards,

K

Hi mspo,

Can you send us an email at support [at] wolfssl [dot] com along with a brief history/background of the project? This inquiry is a bit more advanced than the typical forum case and best handled via our support channel. Thank you!

Warm Regards,

K