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

27

(3 replies, posted in wolfSSL (formerly CyaSSL))

sahl.john,

Can you double check that there is not a previously installed version of the library present on the system? It may be that your system PATH has a copy of /usr/local/include/wolfssl/options.h that is being included INSTEAD of the local wolfssl/options.h that just got generated when configure was run. If there is another copy of options.h that has different settings in it and it is in the system include path it could be causing this issue. Simply remove or uninstall the older headers and library then try building again.

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

karanbanthia,

This kind of restart is most often due to a collision between the heap and stack. Can you try increasing the stack or the heap or both and let us know if the reset issue resolves?

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

Akhi,

Can you double check that the certificate and key you are using for the server are a pair? If you are unsure how to check it I provide an example here awhile back that hasn't yet been merged or reviewed but you can  copy/paste the app to test your cert and key are in fact a pair or not:

https://github.com/wolfSSL/wolfssl-exam … /206/files

Warm Regards,

K

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

- K

laurensiaaverin,

My apologies it is unclear. Here is a link to the code: https://github.com/wolfSSL/wolfssl/blob … 640-L13817

I mean, can u give some example certificate generate with that command line in Linux, please?

I can not, the example we have is programatic. If you need to write a custom little application that takes in user input you could do that easily enough!

I've attached the example cert and key.

Warm Regards,

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

Hi laurensiaaverin,

There is an ntru cert and key provided for testing in wolfssl-root/certs/ntru-cert.pem wolfssl-root/certs/ntru-key.raw.

To generate these one can use the APIs' wc_MakeNtruCert() and ntru_crypto_ntru_encrypt_keygen(). For a reference example please checkout wolfssl-root/wolfcrypt/test/test.c and find the section wrapped by "#ifdef HAVE_NTRU". In that section we create the new key and update the certificate.

Let us know if this helps.

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

akhi_gangwar,

I can confirm we have only tested WOLFSSL_TI_CRYPT on TM4C1294NCPDT, we have not tested the hardware acceleration works correctly on the TM4C129ENCPDT. There are likely some subtle changes that would be required to make it work. Can you confirm that you linked the correct library also to be sure? The build instructions for wolfSSL with TIRTOS will output two separate libraries, wolfssl.aem4f and wolfssl_tm4c_hw.aem4f. If you have the setting WOLFSSL_TI_CRYPT and accidentally link wolfssl.aem4f that can cause issues. Also double check that your application is including <wolfssl/wolfcrypt/settings.h> BEFORE all other wolfSSL headers. If the settings are not included first that can lead to undefined behavior.

Warm Regards,

Kaleb

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

39

(2 replies, posted in wolfSSL (formerly CyaSSL))

If we had to rename it it would be WOLFSSL_OBJECT.

- KH

40

(2 replies, posted in wolfSSL (formerly CyaSSL))

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

41

(2 replies, posted in wolfSSL (formerly CyaSSL))

We will look into it thank you so much for the report!

- KH

@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

@proxion7,

Thank you so much for reaching out about this question. Are you using the meta-wolfSSL project here?

http://github.com/wolfSSL/meta-wolfssl

Can you share a bit more information about your project and goals and what the effort is for?

Warm Regards,

K

can you share details about what it is you are working on and what the product is and will do? If you can not share on the public forum this would be a good candidate to send to our support [at] wolfssl [dot] com domain.

Hi @sreerajsreez7658,

Thank you so much for reaching out to wolfSSL support. You are asking some pretty advanced questions about the use of GCM, can you share details about what it is you are working on and what the product is and will do? If you can not share on the public forum this would be a good candidate to send to our support [at] wolfssl [dot] com domain.

Just a high-level overview:

wc_AesGcmEncrypt(Aes* aes, byte* out, const byte* in, word32 sz,     
                                       const byte* iv, word32 ivSz,               
                                       byte* authTag, word32 authTagSz,           
                                       const byte* authIn, word32 authInSz)

A call to AesGcmEncrypt might look like this:

wc_AesGcmEncrypt( aes, out,  in,  inSz, iv, ivSz,               
                              authTag, authTagSz,           
                              authIn, authInSz);

The authTag is computed by the algorithm and is an OUTPUT.

In 99.9% of use-cases authIn is not set or ever used.

The only time authIn is used is when GCM is used like a block cipher and the authTag OUTPUT from a previous call is passed BACK in as an INPUT so it can be updated in subsequent calls.

I am not sure what you mean when you say "authentication vector" unless you are referring to the authIn I mentioned above which is not typically set (IE its' set to NULL and the length is 0 in most cases and always on the first call to GCM Encrypt or Decrypt).

Warm Regards,

K

46

(1 replies, posted in wolfSSH)

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 selamicandar,

When the issue happens can you try:

1) wolfSSL_free(ssl); ssl = NULL; // Tear down the SSL object.
2) close(socket);
3) open(socket);
4) ssl = wolfSSL_new(ctx); // Re-create a fresh SSL object that is not in an error state.
5) wolfSSL_Connect(ssl); // Re-connect
5) Continue reading/writing.

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

Hi RaghavendraJ,

Thank you so much for reaching out to wolfSSL on the forums. JFYI for best response times feel free to email us at support [at] wolfssl [dot] com anytime.

Can you tell us a bit about the project and what drove this inquiry? Typically requests for Autosar and ISO standards compliance are best handled through our business department, you can reach out to the above mentioned email and we can put you in touch with the business side.

If you have any how-to type technical questions feel free to post them here. Thanks!

Warm Regards,

K

50

(1 replies, posted in wolfCrypt)

Hi sokol.biba,

Can you checkout the wolfSSL manual Chapter 2, section 2.4.7 on "Increasing Performance" and scroll down to the section "wolfSSL’s proprietary Single Precision math support"? I think that will help a lot on this issue!

https://www.wolfssl.com/documentation/w … Manual.pdf

Warm Regards,

K