Hi renminbi,

This is a very interesting case.  These servers are sending a huge certificate message during the SSL/TLS handshake that exceeds the maximum TLS record size.  The TLS RFC states that the maximum TLS record size should be 16k.  For example, looking at the certificate message sent by www.pcmag.com:443 (IP: 192.33.31.80), it is 19097 bytes.

To work around this with wolfSSL, you will need to do two things:

1) wolfSSL limits the maximum certificate chain depth using the MAX_CERTIFICATE_SZ define.  By default this is set to about 18k.  You can increase this by defining it to a larger value at compile time using CFLAGS.  For example:

$ ./configure CFLAGS="-DMAX_CERTIFICATE_SZ=19456"

2)  Increase our internal define which limits the maximum TLS record size to 16k.  This is called MAX_RECORD_SIZE and located in <wolfssl_root>/wolfssl/internal.h.  You can increase this to something larger than the certificate message received by the server.  19k should be good (19456 bytes).

Keep in mind that increasing MAX_RECORD_SIZE creates a non-conformant build which allows records larger than the max allowed size.  A correct TLS implementation should fragment the large certificate message across multiple TLS records instead of stuffing it into a single record that exceeds the max allowed record size.

Best Regards,
Chris

Hi yrekik,

wolfSSL sets a default PSK key using the my_psk_client_cb() and my_psk_server_cb() callbacks in <wolfssl_root>/wolfssl/test.h.  In those functions, you'll see where we set the key, then return the key size:

key[0] = 26;
key[1] = 43;
key[2] = 60;
key[3] = 77;
...
return 4;

Can you verify that this matches the key that you are using on your tiny dtls client/server?

Best Regards,
Chris

Hi Ravi,

Yes, OpenSSL's command line utility should be able to convert .p7b to .pem, similar to:

openssl pkcs7 -in cert.p7b -inform DER -print_certs -out cert.pem

Best Regards,
Chris

Hi Mike,

The K70 provides the mmCAU module for hardware-based cryptography acceleration.  wolfSSL supports offloading into the mmCAU when FREESCALE_MMCAU has been defined.

We have some additional info related to hardware acceleration on Kinetis located on the following page, including some benchmarks comparing software vs. hardware performance:

https://www.wolfssl.com/wolfSSL/wolfssl-freescale.html

Best Regards,
Chris

Hi Mike,

When we created those projects, the "fsl_common.h" header was included as part of the system headers from Freescale.  It's possible that this header has been renamed/removed/changed.  I'll add it to our internal engineering list to circle back and look into why this may have been.

Do you need to stick with classic MQX for your project?  wolfSSL also supports the newer KSDK and KDS, and ships with the KSDK download from Freescale/NXP.

Thanks,
Chris

Hi,

When you are compiling wolfSSL and the C# wrapper, have you defined WOLFSSL_DTLS? This will enable DTLS functionality. You should be able to add this either to your list of preprocessor defines in the project properties, or in the <user_settings.h> file found in the <wolfssl_root>/IDE/WIN directory.

Best Regards,
Chris

Hi,

Do you have the JUNIT_HOME environment variable set?  It should be pointing to the location where the following JAR files are located:

junit-4.12.jar
hamcrest-core-1.3.jar
ant/ant-junit4.jar

Best Regards,
Chris

Hi muyouyuwan,

Thanks for letting us know that Kaleb's suggestions helped.  Glad you got things working!

Best Regards,
Chris

Hi,

Can you please retest this with the current version of the wolfSSL library?  We recently made several changes to wolfCrypt's PKCS#7 support, including a fix when using zero attributes:

https://github.com/wolfSSL/wolfssl/pull/635

Thanks,
Chris

Hi savek,

Thanks for the report.  I am able to reproduce this on my end and am looking into it further.  I'll keep you updated on my status.

Best Regards,
Chris

Hi,

Sure, if you are getting any SSL/TLS or wolfSSL errors, please feel free to post them.

Chris