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

The wolfSSL lightweight SSL/TLS library now supports TLS 1.3 (Draft 18 [1]) on both the client and server side!

A BETA release of wolfSSL (wolfSSL 3.11.1) is available for download from our download page [2]. This release is strictly BETA, and designed for testing and user feedback. Users and customers wanting a stable and production-ready version of wolfSSL should remain on version 3.11.0.

To compile this release with TLS 1.3 support, use the “--enable-tls13” ./configure option:

$ unzip wolfssl-3.11.1-tls13-beta.zip
$ cd wolfssl-3.11.1-tls13-beta
$ ./configure --enable-tls13
$ make

wolfSSL has two new client/server methods, which can be used to specify TLS 1.3 during creation of a wolfSSL context (WOLFSSL_CTX):

WOLFSSL_METHOD *wolfTLSv1_3_server_method(void);
WOLFSSL_METHOD *wolfTLSv1_3_client_method(void);

The wolfSSL example client and server can be used to easily test TLS 1.3 functionality with wolfSSL. For example, to connect the wolfSSL example client and server to each other using TLS 1.3 and the TLS13-AES128-GCM-SHA256 cipher suite, use the “-v” option with “4” to specify TLS 1.3, and the “-l” option to specify the cipher suite:

$ ./examples/server/server -v 4 -l TLS13-AES128-GCM-SHA256
$ ./examples/client/client -v 4 -l TLS13-AES128-GCM-SHA256

Alternatively, the example client can be used to connect to an external server. For example, to connect to the wolfSSL website with TLS 1.3:

$ ./examples/client/client -v 4 -l TLS13-AES128-GCM-SHA256 -h www.wolfssl.com -p 443 -g -A ./certs/wolfssl-website-ca.pem

In this command, “-h” specifies the host, “-p” the port, “-g” causes the client to send an HTTP GET request, and “-A” specifies the CA certificate used to authenticate the server.

wolfSSL currently supports the following TLS 1.3 cipher suites:

TLS13-AES128-GCM-SHA256
TLS13-AES256-GCM-SHA384
TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES128-CCM-SHA256
TLS13-AES128-CCM-8-SHA256

Please send any comments or feedback on wolfSSL’s TLS 1.3 support to support@wolfssl.com. Thanks!

[1] https://tools.ietf.org/html/draft-ietf-tls-tls13-18
[2] https://wolfssl.com/wolfSSL/download/downloadForm.php

53

(7 replies, posted in wolfSSL)

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

The most common culprit for seg faults during math operations is that the wolfSSL library and the application have not been compiled with the same preprocessor defines.

If you are using Autoconf (./configure) to configure and make the library, this will generate the <wolfssl/options.h> header with the defines used during compilation of wolfSSL.  Your application can then simply include <wolfssl/options.h> as the first wolfSSL header include, ie:

#include <wolfssl/options.h>
#include <wolfssl/wolfcrypt/dh.h>

Can you verify that you are using the same preprocessor defines when compiling both wolfSSL and your test app?

If that matches, can you please send me more details about the platform you are compiling on, how you are compiling wolfSSL, and a simple test app that demonstrates the seg fault?

Thanks!
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

Great, glad to hear, thanks for letting me know!

57

(4 replies, posted in wolfSSL)

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

To get this support added to wolfSSL, we can either:

A.  Add this to our internal desired features list.  There is no official timeline associated with features on this list, and they are added as they are received when we get free time in engineering.

B.  Accelerate this feature addition through wolfSSL engineering services.

Which option would you prefer?

Thanks,
Chris

59

(4 replies, posted in wolfSSL)

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

Great, glad to hear you got it resolved!

Best Regards,
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,

wolfSSL doesn't support loading certificates in the .p7b format yet.  We do support loading them through .pem and .der files and/or buffers, and through PKCS#12 bundles.

Are you able to convert your .p7b certificate to a different format, or is .p7b mandatory for your use case?

Best Regards,
Chris

Hi,

As we now encourage users to use wolfSSL over yaSSL, we are deprecating the yaSSL forums and making them read only.

Best Regards,
Chris

Hi,

1° is ant/ant-junit4.jar a file or I should have ant-junit4.jar file in a directory ant of the JUNIT_HOME : usr/share/java/ant/ant-junit4.jar  ?

In this case, "ant/" is a subdirectory under JUNIT_HOME, which then contains "ant-junit4.jar".

2° in which file is the  JUNIT_HOME environment variable set? is it in etc/environment file or in the bashrc file ?

/etc/environment sets variables system-wide, whereas .bashrc will set it only for your user.  You can also set it manually when you open a shell using:

export JUNIT_HOME=/path/to/junit/dir

3° What does indicate the error number (i.e 146 in the error message "BUILD FAILED /home/pitt/wolfssl-jni-1.3.0/build.xml:146: Compile failed; see the compiler error output for details.) after doing some changes I get 146 or 140 or 91,...

When WolfSSLTestSuite fails, there should be a report file generated at:

<wolfssl-jni-root>/build/reports/TEST-com.wolfssl.WolfSSLTestSuite.txt

Can you inspect that file and share what it tells you?

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

A rule of thumb is that the overhead of adding SSL/TLS to a connection will be about 30%, but this will vary depending on what cipher suite and key sizes you are using for the connection.

SSL/TLS also has a maximum record size of 16kB.  Depending on the size of your file being transferred, the more chunks being done will increase the overhead.

We typically run the wolfCrypt benchmarks as a gauge of performance, since the performance of the SSL/TLS layer is directly dependent on the underlying cryptography performance.

The benchmark application source is located in wolfcrypt/benchmark/benchmark.c. For *nix platforms, the benchmark can be ran using ./wolfcrypt/benchmark/benchmark. The benchmark is compiled by default.  If benchmarking on an embedded platform, define BENCH_EMBEDDED to reduce resource use.  For more details regarding benchmarking wolfSSL and reference numbers we have gathered in the past, please reference the wolfSSL and wolfCrypt Benchmarks webpage:

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

Best Regards,
Chris

Hi muyouyuwan,

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

Best Regards,
Chris

68

(12 replies, posted in wolfSSL)

Hey Marco,

Thanks for letting us know about your issue.  I'll forward your question to our SSH expert for a response.

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

As of the following commit, wolfSSL will now request the correct certificate type in the CertificateRequest message when using ECDSA-CHACHA cipher suites.  This will be included in our next stable release of wolfSSL.

https://github.com/wolfSSL/wolfssl/pull … 8489230ed3

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

Circling back around on this topic, wolfSSL 3.9.10 now has support for the TLS Extended Master Secret extension.  This is enabled by default.

Hi,

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

Chris

Hi,

Correct, you will want to use wolfCrypt's API if only interested in doing encryption/decryption operations separate from SSL/TLS.

The wolfCrypt API reference can be found here:
https://wolfssl.com/wolfSSL/Docs-wolfss … rence.html

And, for code examples, one of the best places to look will be at the wolfCrypt test application (./wolfcrypt/test/test.c).  This file contains test code for all of wolfCrypt's crypto algorithms, and as such can act as a good usage example.  Each algorithm has it's own test function.  For example, for AES, the test function is called aes_test().

https://github.com/wolfSSL/wolfssl/blob … est/test.c

There are also a few examples in the "wolfssl-examples" repository on GitHub:

https://github.com/wolfSSL/wolfssl-exam … ter/crypto

Best Regards,
Chris

75

(2 replies, posted in wolfSSL)

Hi,

Have you found our build instructions for Arduino yet?  They are located in the wolfSSL download, under:

<wolfssl_package>/IDE/ARDUINO/README.md

For Windows, there are several different ways to compile wolfSSL.  You can use the steps mentioned in Chapter 2 of the wolfSSL Manual if using Cygwin/MinGW.  Otherwise, we include Visual Studio solution files with the wolfSSL download.  They are located in the root directory of the wolfSSL package.

Do you mind if I ask what kind of project are you working on?

Best Regards,
Chris