Hi srikbn,
The output you mentioned is expected when you have compiled wolfSSL with "--enable-debug" or -DDEBUG_WOLFSSL. This is being output by the wolfCrypt test app when a failure test case is being tested and is expected.
Best Regards,
Chris
You are not logged in. Please login or register.
Please post questions or comments you have about wolfSSL products here. It is helpful to be as descriptive as possible when asking your questions.
ReferenceswolfSSL - Embedded SSL Library → Posts by chrisc
Hi srikbn,
The output you mentioned is expected when you have compiled wolfSSL with "--enable-debug" or -DDEBUG_WOLFSSL. This is being output by the wolfCrypt test app when a failure test case is being tested and is expected.
Best Regards,
Chris
Hi pkolte,
Thanks again for bringing this issue to our attention. This will be fixed in the next release of wolfSSL JNI. We are currently working on a substantial improvement to wolfSSL JNI with the addition of a JSSE provider. This has been fixed as part of that effort. You will no longer need to worry about size limitations when calling WolfSSLSession.write().
Thanks,
Chris
Hi rahuld3919,
If you are trying to connect to a server that has a self-signed certificate (server cert is signed by itself), you have two options:
1) Load the same server certificate into the client as a trusted root certificate. You can do this using the wolfSSL_CTX_load_verify_locations() API.
2) Disable peer verification using the wolfSSL_CTX_set_verify() with SSL_VERIFY_NONE. This will disable verification, and is not recommended.
Best Regards,
Chris
Did you know that wolfSSL, wolfSSH, wolfMQTT, and wolfTPM all support being compiled on Yocto Project [1] or OpenEmbedded [2] based projects? We recently refreshed our layer and recipe files to support the most current product versions, examples, and Open Source project bbappend files.
There are a several ways that projects can include wolfSSL products, or the wolfSSL embedded SSL/TLS library in Yocto Project / OE images. wolfSSL maintains a layer called “meta-wolfssl“, located on GitHub here:
https://github.com/wolfssl/meta-wolfssl
This layer includes recipes for:
wolfSSL embedded SSL/TLS library
wolfSSH lightweight SSH library
wolfMQTT lightweight MQTT Client Library
wolfTPM TPM 2.0 Library
wolfCrypt test application
wolfCrypt benchmark application
cURL .bbappend file, for compiling cURL with wolfSSL support
If you are interested in trying these recipes out, we have a great Getting Started document available here:
wolfSSL Getting Started for Yocto and OpenEmbedded:
https://www.wolfssl.com/docs/getting-st … nembedded/
The wolfSSL product recipe is also part of the “meta-openembedded/meta-networking/recipes-connectivity” layer, located here:
https://github.com/openembedded/meta-op … ty/wolfssl
If you have questions about using “meta-wolfssl” in your project, or need tips on getting started with your build, email us at info@wolfssl.com!
[1] https://www.yoctoproject.org/
[2] http://www.openembedded.org/wiki/Main_Page
Hi Federico,
wc_PKCS7_EncodeSignedData() cannot currently hash the input content in a loop of smaller chunks. That function (in ./wolfcrypt/src/pkcs7.c) is currently set up to call wc_HashUpdate() on "pkcs7->content" in to hash one block of size "pkcs7->contentSz".
To modify this function to hash smaller chunks, you would need to implement a loop around wc_HashUpdate() that loops over smaller sizes before setting the "contentDigest" array offsets and calling wc_HashFinal().
Are you able to share more details about the project you are working on?
Best Regards,
Chris
wolfSSL 3.13.0 is now available for download [1]! wolfSSL 3.13.0 includes bug fixes and new features, including support for TLS 1.3 Draft 21, performance and footprint optimizations, build fixes, updated examples and project files, and one vulnerability fix.
Continue reading below for a summary of the features and fixes included in this release!
Protocol Changes:
* Fixes for TLS 1.3, support for Draft 21
* TLS 1.0 disabled by default, addition of “–enable-tls10” configure option
Performance and Size Optimizations:
* New option to reduce SHA-256 code size at expense of performance (USE_SLOW_SHA256)
* New option for memory reduced build (–enable-lowresource)
* AES-GCM performance improvements on AVX1 (IvyBridge) and AVX2
* SHA-256 and SHA-512 performance improvements using AVX1/2 ASM
* SHA-3 size and performance optimizations
* Fixes for Intel AVX2 builds on Mac/OSX
* Intel assembly for Curve25519, and Ed25519 performance optimizations
* Allow adjusting static I/O buffer size with WOLFMEM_IO_SZ
Build Option Updates:
* New option to force 32-bit mode with “–enable-32bit”
* New option to disable all inline assembly with “–disable-asm”
* Ability to override maximum signature algorithms using WOLFSSL_MAX_SIGALGO
* Removes 3DES and SHA1 dependencies from PKCS#7
* Adds ability to disable PKCS#7 EncryptedData type (NO_PKCS7_ENCRYPTED_DATA)
Feature Additions:
* Add ability to get client-side SNI
* Expanded OpenSSL compatibility layer
* Adds static memory support to the wolfSSL example client
* Adds option to wolfCrypt benchmark to benchmark individual algorithms
* Adds option to wolfCrypt benchmark to display benchmarks in powers of 10 (-base10)
Updated Project Files:
* Updated Visual Studio for ARM builds (for ECC supported curves and SHA-384)
* Updated Texas Instruments TI-RTOS build
* Updated STM32 CubeMX build with fixes for SHA
* Updated IAR EWARM project files
* Updated Apple Xcode projects with the addition of a benchmark example project
Build and Feature Fixes:
* Fixes for handling of unsupported TLS extensions.
* Fixes for compiling AES-GCM code with GCC 4.8.*
* Fixes for building without a filesystem
* Fix for logging file names with OpenSSL compatibility layer enabled, with
WOLFSSL_MAX_ERROR_SZ user-overridable
* Fixes for sniffer to use TLS 1.2 client method
Vulnerability Fix:
This release of wolfSSL fixes 1 security vulnerability.
wolfSSL is cited in the recent ROBOT Attack by Böck, Somorovsky, and Young. The paper notes that wolfSSL only gives a weak oracle without a practical attack but this is still a flaw. This release contains a fix for this report. Please note that wolfSSL has static RSA cipher suites disabled by default as of version 3.6.6 because of the lack of perfect forward secrecy. Only users who have explicitly enabled static RSA cipher suites with WOLFSSL_STATIC_RSA and use those suites on a host are affected. More information will be available on our website at:
https://wolfssl.com/wolfSSL/security/vu … lities.php
For additional documentation, please visit our Docs page, or contact us at info@wolfssl.com.
Hi Manoj,
Can you send us examples of the two public keys? Looking at them may give us some clues as to the difference in formats.
Thanks,
Chris
Hi saleem564,
From your Wireshark screen capture, it looks like a successful TLS handshake is being performed, and application data is being transmitted after the handshake. Can you clarify where in the handshake the timeout is occurring?
Thanks,
Chris
Hi Ornelas,
wolfSSL falls back to including <sys/socket.h> when no other port layers have been enabled. Last time we worked with wolfSSL on an Arduino, we created a define called WOLFSSL_ARDUINO. Are you defining this when compiling wolfSSL?
Further instructions can be found in the following README:
https://github.com/wolfSSL/wolfssl/blob … /README.md
Best Regards,
Chris
Hi dragem,
Are you compiling your application with the same preprocessor defines that were used to compile the wolfSSL library?
If you compiled wolfSSL with the ./configure script, it will have generated a <wolfssl/options.h> header containing all the preprocessor defines used at compile time. You should then include that in your application, as the first wolfSSL header:
#include <wolfssl/options.h>
#include <wolfssl/wolfcrypt/rsa.h>
...
Best Regards,
Chris
Hi Sanjay,
The wolfSSL example client (./examples/client/client.c) uses the following files by default for those functions:
wolfSSL_CTX_use_certificate_chain_file() - ./certs/client-cert.pem
wolfSSL_CTX_use_PrivateKey_file() - ./certs/client-key.pem
wolfSSL_CTX_load_verify_locations() - ./certs/ca-cert.pem
Best Regards,
Chris
Hi cxdinter,
This behavior was fixed starting with release 3.11.0 (released 5/4/2017), and is fixed in all subsequent versions. Are you able to share what company/product you are working with?
Thanks,
Chris
Hi Sanjay,
In client_test.c, you are disabling certificate validation when you call:
wolfSSL_CTX_set_verify(ctx,SSL_VERIFY_NONE ,0);
If you remove this line, your client will try to validate the server's certificate, using the root CA cert you have loaded with wolfSSL_CTX_load_verify_locations(). It looks like you have the incorrect CA certificate loaded (at least looking at the server certificate chain from my end. When I look at your server's certificate chain, I see:
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=demo.valuepaymentsystems.com
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Certification Authority
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
3 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
This means that in order to correctly validate the server, you would need to load the root most CA certificate with wolfSSL_CTX_load_verify_locations(). This would be "AddTrust External CA Root". I have attached this certificate here for you to test.
When I run your test application using the attached certificate, my connection succeeds. Can you capture a Wireshark trace of your connection and send me the .pcap file for analysis?
Thanks,
Chris
Hi Sanjay,
Thanks for sending your certificate over. I noticed that "client.pem" included an encrypted RSA private key. As I wasn't sure if this was a test cert/key pair, I removed your attachment from this post for security reasons but did have a chance to look at the file.
A few notes:
1. client.pem includes three items - a CA certificate, a peer certificate, and an RSA private key
2. You should only load the CA certificate with wolfSSL_CTX_load_verify_locations()
3. The client's certificate (if doing mutual authentication) would be loaded with wolfSSL_CTX_use_certificate_file()
4. The client's private key would be loaded with wolfSSL_CTX_use_PrivateKey_file(), but you first would need to register a password callback using wolfSSL_CTX_set_default_passwd_cb(). The password callback will be called during key decryption, allowing your callback to provide the password.
Regarding "DHE-RSA-AES256-SHA256", can you let me know the exact steps you are taking to compile the wolfSSL library and run the example client that results in you getting the ""DHE-RSA-AES256-SHA256" is undefined" error?
Thanks,
Chris
Hi Sanjay,
Going forward, while i'm using "wolfSSL_CTX_set_cipher_list(ctx, DHE-RSA-AES256-SHA256)" API then getting error: "DHE-RSA-AES256-SHA256" is undefined.
The wolfSSL example client can be used with the "-e" option to view what cipher suites have been enabled for the given build configuration. For example:
$ cd wolfssl-x.x.x
$ ./configure <options>
$ make
$ ./examples/client/client -e
DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305-OLD:ECDHE-ECDSA-CHACHA20-POLY1305-OLD:DHE-RSA-CHACHA20-POLY1305-OLD
Do you see "DHE-RSA-AES256-SHA256" in that list?
Also, wolfSSL_CTX_load_verify_locations(ctx, "client.pem", 0) producing "Error loading .pem file".
Can you verify that "client.pem" exists in your immediate directory? It could also be that "client.pem" includes algorithms or key sizes that wolfSSL has not been compiled to support. Are you able to share "client.pem"? If not, can you look and see what algorithms and key sizes are used by that certificate?
Thanks,
Chris
Hi Nimesh,
Are you able to capture a Wireshark trace of the failing connection?
Thanks,
Chris
Internally wolfSSL uses the EmbedSend() and EmbedReceive() callback functions in ./src/io.c to send and receive data. This is where we call the normal BSD send/recv functions by default. It may help to take a look here and see what the normal socket function is receiving to better understand wolfSSL's error codes as well.
In EmbedReceive() for example, if recv() has set errno to SOCKET_EWOULDBLOCK, SOCKET_EAGAIN, or SOCKET_ECONNREFUSED, we return WOLFSSL_CBIO_ERR_WANT_READ which gets propogated back up to the application layer as SSL_ERROR_WANT_READ from wolfSSL_get_error().
Best Regards,
Chris
Hi Nimesh,
The "-326" error is a record layer version error (VERSION_ERROR). Are you sure that the server you are connecting to supports TLS 1.2?
Best Regards,
Chris
By default, our configure script only compiles a shared library, to enable compilation of a static library, use the "--enable-static" option:
$ cd wolfssl-x.x.x
$ ./configure --enable-static
$ make
Best Regards,
Chris
wolfSSL_get_error() should return SOCKET_PEER_CLOSED_E in the case where the peer has reset or closed the socket.
Best Regards,
Chris
Hi andrey.ribalko,
Thanks for the report. I'll make a note of this internally and see if we can look getting this resolved. Are you able to get the rest of the hardware crypto integration working on your STM32F2?
Thanks,
Chris
Hi Nimesh,
If wolfSSL_connect() fails, you can then call wolfSSL_get_error() to get the exact error code. Can you do this and let me know what error code you are receiving?
Thanks,
Chris
Hi Nimesh,
It is helpful in cases like this to enable wolfSSL debug logging. Are you able to do this? You can enable debug messages by compiling wolfSSL with DEBUG_WOLFSSL defined, then calling wolfSSL_Debugging_ON() as the first wolfSSL API called by your application.
By default, log messages with print to stderr using fprintf().
Thanks,
Chris
Hi muyouyuwan,
When using non-blocking sockets with wolfSSL, wolfSSL returns SSL_ERROR_WANT_READ when there is no data available to be read on the socket, or SSL_ERROR_WANT_WRITE when data is not able to be written to the socket at the given time.
In either of these cases, the application needs to call the wolfSSL API (in your case wolfSSL_recv()) when data is available. Your application is expected to know when data is available on the socket, or poll the wolfSSL API periodically. Oftentimes, applications will call select() on the socket to wait for data to become available for reading.
Best Regards,
Chris
Hi kanaziwok,
We are actively developing our TLS 1.3 implementation, but also maintaining and progressing our TLS 1.2 implementation.
There are a couple ways we can add features to wolfSSL and/or wolfSSL JNI. I can add your request to our feature request list. This is a list that we get to as our engineering team gets time. There is no timeline associated with features on this list.
The second option is to add functionality as part of our consulting services. Do you have a preference between these routes?
Thanks,
Chris
wolfSSL - Embedded SSL Library → Posts by chrisc
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.013 seconds (49% PHP - 51% DB) with 5 queries