NOTE: Being handled in Zendesk, if a solution can be reached it will be posted here for public review.

Hi Carsonbaker,

Currently wolfSSL has not worked on SRTP solution but it is something we would love to discuss with you! Your project sounds interesting and we would love to hear more details, what are your end goals, what problem will SRTP w/ DTLS help you solve?

Warm Regards,

Kaleb

Hi oigor,

It does seem like the logic should be only "greater than" following my initial review. I want to spend a little more time checking one thing, but wanted to get you an update. I will let you know when I have completed a more in-depth review of the other code segments surrounding this condition.

If possible could you provide us the test certificates you are using so we might reproduce the issue on our end and create a test case for this scenario in all our future release cycles?

Warm Regards,

Kaleb

Hi yrekik,

Are you positive tinyDTLS support POLY1305 and CHACHA? That is a pretty cutting edge cipher suite that will make it into TLS 1.3 but very few vendors support it today. wolfSSL and BoringSSL support that cipher suite but very few other SSL/TLS/DTLS providers have taken that step so far, I am skeptical that tinyDTLS supports it.

That being said I can confirm the issues you previously noted when using PSK-AES128-CCM-8 and I am looking into the issue. I should have more info for you by Friday morning Mountain Standard Time (U.S).

Warmest Regards,

Kaleb

Hi telina,

As Chris initially pointed out it sounds like you have a configuration mismatch. In the configuration you sent you have the configure option

--enable-fastmath

Then in the Netbeans project it has "Unresolved includes" in "wolfssl/wolfcrypt/dh.h" leading to "integer.h". HOWEVER "integer.h" is the normal math libraries and SHOULD NOT be being built when using FASTMATH, instead that should be "tfm.h" (short for tom's fast math).

It sounds like the Netbeans project still does not have the same settings as the library was built with. Could you double check that the Netbeans project is including "wolfssl/options.h" header file?

Warmest Regards,

Kaleb

Hi embedded,

In non-blocking mode a timeout should never be reached, ever. The timeout is for one specific "blocking mode" case:

BLOCKING MODE:

1. server and client are connected.
2. Server advances TLS state machine to a "read" state and enters the receive data method.
3. Client ungracefully disconnects (network goes down temporarily or something else unexpected happens)
4. Server gets stuck waiting to receive data FOREVER.
5. Insert TIMEOUT, now server will only get stuck waiting to receive until timeout is reached.
6. Now server has a way to back out and see that the client has disconnected and aborts the session.

NON-BLOCKING MODE:

1. <same as 1 in blocking mode>
2. <same as 2 in blocking mode>
3. <same as 3 in blocking mode>
4. Server checks to see if there is data. No data waiting, returns immediately in non-blocking mode.
5. No need for a timeout
6. server always returns regardless of data or not, sees that the client has disconnected and aborts the session.

There are two layers that play a role in non-blocking, the TCP/IP layer and the TLS layer. Could you make sure that the TCP/IP socket is also configured non-blocking at the TCP level? If you are still getting a TIMEOUT while using WOLFMQTT_NONBLOCK, that means non-blocking mode is not completely configured correctly.

Best Regards,

Kaleb

Hi djohnson,

PKCS 5 v2.1 is definitely something we could add but as you noted we don't have it yet. For new feature requests tracking, if it's not too much trouble, could you shoot an email to "support@wolfssl.zendesk.com" so I can more easily track that request.

Also when you send the email could you provide just some high-level overview of the project you are working on, any time-lines you may be aware of for the project etc.

Once I receive the feature request email I'll put you in touch with Rich Kelm and alert him of the request to start discussing the best way to approach this based on your project and any timelines you might have.

Thanks!

Kaleb

Hi M. Colella,

Could you tell us the end goals of your project, what are you working on, what will it do? We love to hear about all the new and exciting ways people are using our embedded TLS/SSL library!

There are many customers using wolfSSL on MQX today. If you execute this google search you will find a lot of hits on the forums here with many helpful suggestions and issues some of our users have had when building for the first time with MQX:

Google Query:

The guide for building wolfSSL (Formerly known as CyaSSL) can be found on the NXP site here: https://community.nxp.com/thread/338562

Our product comes bundled. It is called "CyaSSL for Kinetis SDK with MQX RTOS"

Once you are up and running with the wolfSSL library the MQTT guide can be found here: https://wolfssl.com/wolfSSL/Docs-wolfmqtt-manual.html

It should not be too difficult to port MQTT as all the underlying security relies on the wolfSSL library which has already been ported. Once you get to that step though, if you have any trouble please let us know, we are happy to help any way we can.

We have not personally ported our MQTT solution to MQX yet as it is still a newer product but we're happy to assist you in the effort.

Thank you for using the wolfSSL Forums!

Best Regards,

Kaleb

Hi Nimesh,

Ok thanks for confirming the need for client authentication.

To correctly do client-auth you need to load the CA that signed the client's certificate on the server side with the API wolfSSL_CTX_load_verify_locations(Take file input) or wolfSSL_CTX_load_verify_buffer(takes buffer input if you don't have a file system) prior to the client connecting to the server. You can see examples of this being done in <wolf-root>/examples/server/server.c when "doCliCertCheck" is set to 1 (by default).

Best Regards,

Kaleb

If the clients certificate is self-signed then you need to load the clients actual certificate with that API on the server prior to the client connecting.

Hi Teaspoon,

Could you tell me more about your project and end goals? What platform are you working on, what architecture?
Have you run the wolfcrypt test application to confirm the underlying crypto is working on your platform?

( <wolf-root>/wolfcrypt/test/test.c )

I ask because I literally just copy/pasted your code, compiled it and my result was:

kalebs-MBP:support-forums-IV-being-changed-3-apr-2016 khimes$ ./run 

IV before SetKey(Encrypt): 31 32 33 34 35 36 37 38 39 30 61 62 63 64 65 66 
IV  after SetKey(Encrypt): 31 32 33 34 35 36 37 38 39 30 61 62 63 64 65 66 
 aesEncrypt.reg  contents: 31 32 33 34 35 36 37 38 39 30 61 62 63 64 65 66 
IV  after SetKey(Decrypt): 31 32 33 34 35 36 37 38 39 30 61 62 63 64 65 66 
 aesDecrypt.reg  contents: 31 32 33 34 35 36 37 38 39 30 61 62 63 64 65 66 
Plain1: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 00 
AAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
Padded: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 00 05 05 05 05 05 
Cipher: 8A D4 F6 7D 53 E1 FA 88 36 9C 83 00 D8 A5 1A 60 FB 26 CC A5 22 46 AA F2 2E 9A 5A 40 9E AD EE 7B ED 35 48 36 9E D5 4D E3 7B CD 5A 1D 3D 85 A7 70 DE 86 3C 27 61 0E 00 14 B2 69 34 03 3A 2C 25 0E 
Plain2: 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 41 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 42 00 
AAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB

I also noticed you did not include <wolfssl/options.h> or <wolfssl/wolfcrypt/settings.h> in your project. You should include the same settings file that you used to configure wolfSSL library so your application and the library are not in conflict. If the library and the application linking against the library are in conflict you may experience undefined behavior.

Let me know some more details so we can narrow down why you are seeing this result on your platform/device.

Warm Regards,

Kaleb

I would recommend disabling client authentication on the server side. IE on the server you would not want to use the API "wolfSSL_CTX_set_verify"

If you do not call that API then client authentication will be disabled by default.

Do you intend to do client auth?

- Kaleb