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,
Thanks for the bug report. This has been fixed with the following commit:
https://github.com/wolfSSL/wolfssl/comm … a1a30f3c95
Thanks,
Chris
Hi,
Thanks for the detailed report and attached example code. Let me look into this and get back to you shortly.
Thanks,
Chris
wolfSSL 3.9.10 Now Available
Version 3.9.10 of the wolfSSL embedded SSL/TLS library is now available for download. This release contains bug fixes, new features, and includes fixes for three medium level vulnerabilities.
Vulnerabilities fixed by this release include CVE-2016-7440, CVE-2016-7439, and CVE-2016-7438, as explained in this recent wolfSSL blog post (https://wolfssl.com/wolfSSL/Blog/Entrie … Fixes.html). This includes fixes for potential AES, RSA, and ECC side channel leaks that a local user monitoring the same CPU core cache could exploit. VM users, hyper-threading users, and users where potential attackers have access to the CPU cache will need to update if they utilize AES, RSA private keys, or ECC private keys. Thanks to Gorka Irazoqui Apecechea and Xiaofei Guo from Intel Corporation for the report.
Other changes and new features in this release are described below.
Default Configure Option Changes
3DES (--enable-des3) is disabled by default. 3DES has been disabled for security after the Sweet32 attack was announced.
ECC Supported Curves Extension (--enable-supportedcurves) is enabled by default. The ECC Supported Curves Extension, when enabled, broadcasts the ECC curves supported by the client in the Client Hello message.
TLS Extended Master Secret (--enable-extended-master) is enabled by default. The 3SHAKE attack demonstrated how an active attacker can synchronize two TLS sessions so that they share the same "master_secret". As per RFC 7627, this extension “changes the way the "master_secret" value is computed in a full handshake by including the log of the handshake messages, so that different sessions will, by construction, have different master secrets.”
Added checking CA certificate path length, and new test certs
From RFC 5280, “the basic constraints extension identifies whether the subject of the certificate is a CA and the maximum depth of valid certification paths that include this certificate.” The path length constraint field (pathLenConstraint) specifies the maximum number of non-self-issued intermediate certificates that may follow a given CA certificate in a certificate chain.
wolfSSL now checks the path length between an intermediate CA certificate and its signer’s path length, always decodes the path length if present, and saves the path length into the signers list. The path length is capped at 127 certificates. New test certificates have been added for this scenario, located under the “./certs/test-pathlen” directory.
Fix to DSA pre padding and sanity check on R/S values
This fix adds pre padding of DSA signature with zeros and adds sanity checks for R/S values during DSA sign operations to make sure they are not zero.
Added CTX level RNG for single-threaded builds
In SINGLE_THREADED mode wolfSSL has a new API, wolfSSL_CTX_new_rng(), that creates an RNG object at the WOLFSSL_CTX level that is shared with each created WOLFSSL session object. This is only allowed in SINGLE_THREADED mode because otherwise locking/blocking would be needed. The benefit to this CTX-level RNG is there is only one RNG object to seed and this also saves 200 bytes or so from each WOLFSSL session. It can be called immediately after wolfSSL_CTX_new(), the example client now uses it in SINGLE_THREADED mode.
Intel RDSEED enhancements
Improvements to Intel RDSEED include:
Increase RDSEED retries to 32, still an order of magnitude faster than /dev/urandom
Increase RDSEED retrieval to 64bits, halving the number of calls
Allow fallback to /dev/urandom on retry failure
Allow fallback override (that is hard failure) with FORCE_FAILURE_RDSEED which does not fallback to /dev/urandom
ARMv8 hardware acceleration support for AES-CBC/CTR/GCM, SHA-256
Users running wolfSSL on ARMv8 now have access to increased performance through hardware acceleration integration. More details can be found in this blog post, or by emailing us directly.
Arduino support updates
Interested in securing your Arduino-based project? Arduino build instructions and build script have been updated to make building wolfSSL for Arduino environments more intuitive. Arduino build instructions can be found in “./IDE/ARDUINO/README.md” located in the wolfSSL download package.
Added the Extended Master Secret TLS extension
Support for the TLS Extended Master Secret extension has been added to wolfSSL, both at the SSL/TLS and sniffer levels. This extension is enabled by default and can be disabled through the provided API functions (reference the wolfSSL Manual for API and usage).
OCSP fix with issuer key hash, lookup refactor
This includes two fixes. The first for the wolfSSL CertManager OCSP lookup where the issuer key hash wasn’t being set correctly and could lead to unknown responses from the lookup. The second fix addresses the default OCSP lookup callback which previously could get blocked waiting for the server to close the socket.
Added support for Frosted OS
wolfSSL now has support for the Frosted (Free POSIX OS for tiny embedded devices) operating system. More information about FROSTED can be found in their GitHub repository.
Added support for DTLS over SCTP
wolfSSL has added support for DTLS over SCTP (Stream Control Transmission Protocol). If you are not familiar with SCTP, from Wikipedia, “SCTP provides some of the same service features of both [TCP and UDP]: it is message-oriented like UDP and ensures reliable, in-sequence transport of messages with congestion control like TCP; it differs from these in providing multi-homing and redundant paths to increase resilience and reliability.”
wolfSSL has a new configure option to enable DTLS-SCTP support called “--enable-sctp”, and now includes example tools and test applications under the “./examples/sctp” directory. These include an SCTP Client, Server, and DTLS-SCTP Client and Server.
Added support for static memory with wolfCrypt
wolfCrypt now has the ability to use only static memory with the wc_LoadStaticMemory() function. The wolfCrypt test and benchmark applications can use this functionality when WOLFSSL_STATIC_MEMORY is defined.
Fix to ECC Custom Curve support
This includes a fix for wc_ecc_set_custom_curve() not setting the index as ECC_CUSTOM_IDX and also includes cleanup of the ECC test cases.
Support for asynchronous wolfCrypt RSA and TLS client
Added asynchronous wolfCrypt RSA, TLS client and Cavium Nitrox V support including asynchronous wolfSSL client support for "DoServerKeyExchange", "SendClientKeyExchange", "SendCertificateVerify" and "DoCertificateVerify". This includes fixes for asynchronous DTLS, a refactor of the event and asynchronous handling for use in wolfCrypt, and a refactor of the async device support so it is hardware agnostic.
Added Cavium Nitrox V support (Nitrox tested using SDK v0.2 CNN55XX-SDK with new configure "--with-cavium-v=/dir" option) and Nitrox specific functions have been moved to a new port file called "port/cavium/cavium_nitrox.c".
RSA has been refactored to handle async with states including RSA optimization for using dpraw for private key decode. wolfCrypt test and benchmark support for async RSA has been added. Asynchronous mode can now be enabled using "./configure --enable-asynccrypt". If no async hardware is defined then the internal async simulator (WOLFSSL_ASYNC_CRYPT_TEST) is used. Note: Using async mode requires async.c/h files from wolfSSL. If interested in using asynchronous mode please send email to info@wolfssl.com.
Added distribution build configure option
For easier creation of OS and Distribution packages, a new ./configure option has been added called “--enable-distro”. Package maintainers should now use this option instead of hand picking options themselves for wolfSSL packages. This will guarantee that ./configure options are enabled/disabled as the wolfSSL engineers recommend.
Update the test certificates
The wolfSSL test certificates have been updated so that they now all have the same expiration date. Additional DER formatted test certificates, including ECC ones, have been added.
Please contact wolfSSL at info@wolfssl.com with any questions about new features or fixes made in this release of wolfSSL.
References:
wolfSSL Embedded SSL/TLS Library: https://www.wolfssl.com/wolfSSL/Products-wolfssl.html
Download wolfSSL: https://wolfssl.com/wolfSSL/download/downloadForm.php
wolfSSL release 3.9.10 fixes 3 medium level security vulnerabilities:
CVE-2016-7440 The C software version of AES Encryption and Decryption in wolfSSL 3.9.8 and earlier uses a T-table based implementation where Table lookups do not properly consider cache-bank access times. This makes it easier for a local user to discover AES keys by running a crafted application on the same machine as a victim and leveraging cache-bank timing differences.
CVE-2016-7439 The C software implementation of RSA in wolfSSL 3.9.8 and earlier uses a different variable during squaring depending on the key state and does not properly consider cache bank monitoring. This makes it easier for a local user to discover RSA keys by running a crafted application on the same CPU core as a victim and leveraging cache-bank hit differences.
CVE-2016-7438 The C software implementation of ECC in wolfSSL 3.9.8 and earlier uses a different variable during doubling depending on the key state and does not properly consider cache bank monitoring. This makes it easier for a local user to discover RSA keys by running a crafted application on the same CPU core as a victim and leveraging cache-bank hit differences.
VM users, hyper-threading users, and users where potential attackers have access to the CPU cache will need to update if they utilize AES, RSA private keys, or ECC private keys.
Thanks to Gorka Irazoqui Apecechea and Xiaofei Guo from Intel Corporation for the reports.
If you have a need for an embedded SSL/TLS library or any questions please contact us today at info@wolfssl.com.
Hi Will,
If you are using the wolfSSL Visual Studio project files for Windows, you can add or change the defines that are used to compile the library in the following file:
./IDE/WIN/user_settings.h
Adding the "WOLFSSL_STATIC_RSA" define will enable static key RSA cipher suites.
Best Regards,
Chris
Hi pstudni,
Thanks for the detailed report and key file. We'll work on reproducing this issue and get back to you shortly.
Thanks,
Chris
The issue here is that wolfSSL_EVP_get_digestbynid() doesn't currently support the SHA384 nid.
wolfSSL_EVP_get_digestbynid() currently only handles MD5 and SHA1 nid types. This is causing the WOLFSSL_EVP_MD* to be NULL, and since it is not being checked before the HMAC() function where the seg fault happens.
wolfSSL/wolfCrypt supports SHA-384 through our native API in either:
<wolfssl/wolfcrypt/sha512.h>
int wc_InitSha384(Sha384*);
int wc_Sha384Update(Sha384*, const byte*, word32);
int wc_Sha384Final(Sha384*, byte*);or through our hash API in:
<wolfssl/wolfcrypt/hash.h>
Best Regards,
Chris
Hi SWS,
You mentioned that you are doing command line builds. Does this mean you are cross compiling, or are you compiling directly inside a VxWorks environment with gcc/ld/etc available?
If you can send me a snapshot of the steps you took to try and compile, along with the errors you are seeing, we can go from there.
Thanks,
Chris
Hi SWS,
When we ported wolfSSL to VxWorks we were using the Wind River Workbench. Instructions on how we did that previously can be found in the following file located in the wolfSSL download:
<wolfssl_package>/IDE/WORKBENCH/README.md
Alternatively, if you have a VxWorks toolchain set up, you should be able to use the Autoconf (./configure) system to cross compile wolfSSL for VxWorks following steps similar to those in Section 2.6 of the wolfSSL Manual [1], ex:
./configure --host=<your-host> CC=<your-cc> LD=<your-ld> AR=<your-ar> RANLIB=<your-ranlib> C_EXTRA_FLAGS="-DWOLFSSL_VXWORKS".If you can elaborate on the errors you were seeing, I can try to help you through those as well.
Best Regards,
Chris
Hi,
That is correct. The CSR must be signing with the applicant's private key, which is why the wc_SignCert() function is used. Since most CA's would expect a PEM-formatted CSR, wc_DerToPem() is used to convert the DER encoded CSR to a PEM formatted one.
Best Regards,
Chris
Hi SWS,
wolfSSL has a define specific to compiling for VxWorks, called WOLFSSL_VXWORKS. You will want to define this when compiling the wolfSSL library.
We also have a define called VXWORKS_SIM which should be defined if compiling for use with the VxWorks simulator instead.
Let us know if you run across any issues when compiling and we'll be happy to do our best to help.
Best Regards,
Chris
Hi,
I just created an example of reading a DER-formatted certificate then extracting the public key and subject name information using wolfSSL. The example requires wolfSSL to be compiled with the OpenSSL compatibility layer for access to some functions (--enable-opensslextra, or -DOPENSSL_EXTRA).
The example is currently in the following pull request. I will update this link when the PR gets pulled into the "wolfssl-examples" repository:
https://github.com/wolfSSL/wolfssl-examples/pull/24
For a PEM formatted certificate, you will first need to read the file in and convert it to DER format using wolfSSL_CertPemToDer().
Best Regards,
Chris
Thanks for the info, and glad to help!
wolfSSL is a growing company looking to add a top notch embedded systems software engineer to our organization. We develop, market and sell the leading Open Source embedded SSL/TLS protocol implementation, wolfSSL. Our users are primarily building devices or applications that need security. Other products include wolfCrypt embedded cryptography engine, wolfMQTT client library, and wolfSSH.
Operating environments of particular interest to us include Embedded Linux and RTOS varieties (VxWorks, QNX, ThreadX, uC/OS, MQX, FreeRTOS, etc). Experience with mobile environments like Android and iOS is a plus.
Currently, we are seeking to add a senior level C engineer interested in a fun company with tremendous upside. Backgrounds that are useful to our team include networking, security, and hardware optimizations. Assembly experience is a plus. Experience with encryption software is a plus. RTOS experience is a plus.
Location is flexible. For the right candidate, we’re open to this individual working from virtually any location.
How To Apply
To apply or discuss, please send your resume and cover letter to info@wolfssl.com.
wolfSSL is interested in hiring an experienced web developer to redesign and maintain the wolfSSL website. This will be a full time position as an employee of wolfSSL. Responsibilities will include website redesign, development, and maintenance as well as writing and improving product documentation. The website will have both static and dynamic content, including a blog and product download pages.
The ideal candidate will have experience with modern web tools and frameworks, experience with web server setup and maintenance, good technical writing skills, and have a passion for cryptography and security fields.
Responsibilities:
+ Redesign of the wolfSSL website, based on a modern web framework
+ Integration of a dynamic blogging platform
+ Creation and maintenance of software documentation
+ Maintenance, expansion, and optimization of the wolfSSL website and forums
Requirements:
+ Knowledge of HTML, CSS, PHP, and modern web languages
+ Familiarity and experience with web and blog frameworks
+ Knowledge of web design best practices
+ Knowledge of back end database systems, such as MySQL
+ Knowledge of SEO and search engine compatibility
+ Team player, able to work well either individually or in a group
+Interest in cryptography and security software
+Proficient technical writing skills
How to Apply:
If interested in applying, please send your resume to info@wolfssl.com. wolfSSL product and company details can be found online at www.wolfssl.com.
The error you are seeing in the debug log is just showing that the peer closed the connection. This isn't showing up in a non-debug log since the example client is not treating it as an error.
Glad you are getting the chance to learn about SSL/TLS! What type of application are you working on?
As an addition to my last email, it could be the SSL/TLS protocol version as well. The wolfSSL example client uses the "-v" option to specify the protocol version, where:
-v 1 TLS 1.0
-v 2 TLS 1.1
-v 3 TLS 1.2If you have access to the "openssl s_client" application, that might also be a helpful way to test what a different implementation connects to your server with regards to protocol version and cipher suite. To use s_client, you can connect using:
$ openssl s_client -connect host:portBest Regards,
Chris
Hi,
The "40" error is simply reflecting the Fatal Alert message being received by the client.
It would be helpful to try and find out what cipher suites your server supports. My guess is that the cipher suites you have enabled in wolfSSL don't include ones that are enabled on the server. Do you have a way to find out what cipher suites are supported by your server?
If you can access your server IP:port, you could use nmap to scan the server for supported cipher suites:
$ nmap --script ssl-enum-ciphers -p 443 <host>A few other options which you can try enabling in wolfSSL:
1. AES-GCM support (--enable-aesgcm)
2. Static key RSA cipher suites (./configure <options> C_EXTRA_FLAGS="-DWOLFSSL_STATIC_RSA"
Best Regards,
Chris
Hi,
"-313" means that the server has sent back a Fatal Alert to the client. If this happens after the ClientHello message is sent, this most likely means that the client is not broadcasting support for a cipher suite or extension that the server requires.
To more accurately suggest a fix for the issue, can you provide:
1. wolfSSL debug log. You can enable debugging by compiling wolfSSL with "--enable-debug".
2. Is this a publicly available server? If so, can you share the host:port where we can reproduce the issue?
Some common solutions to this problem may be:
- If using ECC, the server requires the Supported Curves Extension to be enabled. Compile wolfSSL with "--enable-supportedcurves" to resolve.
- wolfSSL has static key cipher suites disabled by default for security. Please see note at the top of the README for instructions on re-enabling static-key cipher suites if your server requires them.
Thanks,
Chris
Hi,
At the time our PKCS#7 implementation was written, it only needed to support DES and 3DES encrypt cipher types for EnvelopedData.
I have added this request to our desired features list.
Thanks,
Chris
agushimuso,
The hardware crypto for the STM32F2 may be slightly different than the STM32F4, correct. The F4 may need some slight modifications to work correctly.
luanxbach,
Sure! SNI being required, but not used has been a common issue in the last few months. Because of this, it was one of the first things I checked.
Best Regards,
Chris
Hi luanxbach,
It looks like "dl-media.integration.viber.com:443" requires SNI (Server Name Indication) to be used. You can compile wolfSSL with SNI support using the --enable-sni configure option. After adding that, you can connect using the example client by doing:
./examples/client/client -h dl-media.integration.viber.com -p 443 -d -g -S dl-media.integration.viber.comBest Regards,
Chris
Hi earlenceferns,
Thanks for sending over your debug log. That helps clarify things for me.
wolfSSL doesn't currently call the verify callback during CA certificate processing in wolfSSL_CTX_load_verify_locations(). We try to process the certificate chain, then just return an error if the any of them failed to verify/load. The verify callback does get called during the SSL/TLS connection when the client/server is authenticating and verifying the peer certificate.
Reasoning for not including the verify callback in wolfSSL_CTX_load_verify_locations() is simply to avoid potential security problems and application vulnerabilities where the CA certificate verification can be skipped/overridden.
Best Regards,
Chris
Hi Colin,
Thanks for the report! Looking into this and will get back to you shortly.
Best Regards,
Chris
Hi Snuggle,
We haven't tested compiling wolfSSL together with NTRU on iOS with XCode yet. wolfSSL itself can be compiled on iOS with XCode, but I'm not sure if Security Innovation has tested compiling NTRU for iOS.
Are you able to share any details about the project you are working on?
Best Regards,
Chris
wolfSSL - Embedded SSL Library → Posts by chrisc
Powered by PunBB, supported by Informer Technologies, Inc.
Generated in 0.026 seconds (72% PHP - 28% DB) with 4 queries