RECENT BLOG NEWS

wolfSSH v1.2.0 has dropped! We have just added support for Elliptic Curve algorithms and AES-GCM. The following key exchange and public key algorithms are now available:

• ecdh-sha2-nistp256
• ecdh-sha2-nistp384
• ecdh-sha2-nistp521
• ecdsa-sha2-nistp256
• ecdsa-sha2-nistp384
• ecdsa-sha2-nistp521

The wolfSSH SSH server provides the encryption algorithm “aes128-gcm@openssh.com”, which is an implementation of RFC 5647 using the MAC algorithm implied with using the AEAD algorithm AES-GCM. The wolfSSH library provides the messages for including in a client application. Also included is a build solution for MS Visual Studio.

wolfSSH v1.2.0 works best with wolfCrypt v3.12.2. The wolfCrypt/wolfSSL configure script has a wolfSSH enable option to simplify building. Download wolfSSH from the wolfSSL download page today!

STARTTLS is a way of protecting email communications from malicious users (insiders or otherwise) by upgrading a plaintext SMTP connection to one secured by SSL/TLS.  SMTP using STARTTLS allows encryption of emails in transit between email clients and servers. Without encryption email messages can easily be intercepted and read at any point between the sender and the receiver.

wolfSSL has had multiple inquiries about STARTTLS and how to use wolfSSL for the TLS encryption in this protocol. Due to the volume of inquiries over the past few months, we have added an example of using STARTTLS with wolfSSL to the wolfSSL example client. To try it out download wolfSSL from the wolfSSL download page.

Instructions to build and run the examples included with the library can be found at:

Linux/Unix
Windows

Below is a quick example of connecting to GMail’s SMTP server with the wolfSSL example client.  This will open a plaintext communication, use STARTTLS to convert to a SSL/TLS-encrypted channel, then close the connection.

Linux/Unix: ./examples/client/client -h smtp.gmail.com -p 587 -M smtp -d
Windows: client.exe -h smtp.gmail.com -p 587 -M smtp -d

-h specifies the host server to connect to (smtp.gmail.com)
-p specifies the port to connect on (587 for email submission)
-M tells the example client to use STARTTLS with protocol (smtp in this case)
-d tells the client not to authenticate the peer
( to do peer authentication you can download Google’s CA and replace -d option with: “-A /path/to/google-CA”)

If you have any questions or comments please contact wolfSSL at facts@wolfssl.com or visit the wolfSSL support forums.

– The wolfSSL Team

A recent paper titled “Exploiting Dissent: Towards Fuzzing-based Differential Black-Box Testing of TLS Implementations” was published by Axel Sikora and Andreas Walz. wolfSSL found the paper both well composed and informative. We would like to congratulate Andreas and Axel on a well composed piece of literature and we would highly recommend reading it if you have the time!

This paper details a new differential testing method for fuzz testing and we will follow their research closely in the coming year. We hope to see more from Axel and Andreas soon. Until then, CHEERS and keep up the great work!

https://ivesk.hs-offenburg.de/fileadmin/Einrichtungen/ivesk/files/preprint_TLS-Diff-Fuzzing_IEEE-TDSC.pdf

If you have any questions, comments, or feedback please contact us anytime at support@wolfssl.com or facts@wolfssl.com

wolfSSL has a goal: “wolfSSL will provide the best security in the world for all to benefit”! We are very passionate about keeping our users safe and secure in an increasingly connected online world. To that end the wolfSSL product is the most thoroughly tested cryptography and TLS solution on the market today. wolfSSL appreciates and admires those who take the time and effort to implement tools that assist in making our goal a reality!

We recently were made aware of a tool being actively developed called “TLS-Attacker”. TLS-Attacker accomplishes “Systematic Fuzzing and Testing of TLS Libraries”.  This tool was developed by the Ruhr University Bochum and the Hackmanit GmbH . wolfSSL is evaluating this tool for integration with our Jenkins/Hudson continuous integration server and we wanted to give a “SHOUT OUT” to all the developers who worked on this or other similar fuzzing tools! Tools like this help to ensure secure SSL/TLS implementations and we look forward to working with TLS-Attacker. We want to say, “THANK YOU” to the Ruhr University Bochum staff and Hackmanit staff for their efforts!

For any questions, concerns or comments please contact us anytime at support@wolfssl.com or facts@wolfssl.com!

wolfSSL 3.12.2 is now available for download! This release includes many performance improvements with Intel ASM (AVX/AVX2) and AES-NI. wolfSSL has implemented a new single precision math option to speed up RSA, DH and ECC in this release. Embedded hardware support has been expanded for STM32, PIC32MZ and ATECC508A, and AES-XTS mode support has been added for use with disk encryption.

There have been improvements to some of our certificate API’s that allow for setting the serial number, key usage and extended key usage. A refactor of the `SSL_` API’s and hash types has been performed to allow OpenSSL coexistence. There have been improvements made for TLS 1.3 support in this release. A fix was implemented for OCSP stapling to prevent sending the extension unexpectedly, WOLFSSL specific user contexts were added for callbacks, and there were fixes for some OpenSSL and MySQL compatibility functions. The wolfSSL Micrium port was updated for Micrium uC/OS-III, and there were fixes implemented for asynchronous modes as well.

Continue reading below for a summary of the features and fixes included in this release!

General Improvements:

• Speedups for SHA2, ChaCha20/Poly1035 using AVX/AVX2
• Speedups for AES GCM with AES-NI (–enable-aesni)
• New Single Precision math option for RSA, DH and ECC (See –enable-sp) (all off by default).
• Math updates and added TFM_MIPS speedup
• Fixes for HAVE_INTEL_MULX
• Added AES XTS mode (–enable-xts)
• Rename the file io.h/io.c to wolfio.h/wolfio.c
• Cleanup the wolfIO_Send function
• Improvements to Visual Studio DLL project/solution
• Added function to generate public ECC key from private key
• Added async blocking support for sniffer tool
• Updated Micrium uC/OS-III Port

TLS v1.3:

• Fixes for various TLS 1.3 disable options (RSA, ECC and ED/Curve 25519)
• Fix to disallow upgrading to TLS v1.3
• Fixes for wolfSSL_EVP_CipherFinal() when message size is a round multiple of a block size
• Add HMAC benchmark and expanded AES key size benchmarks
• Added simple GCC ARM Makefile example (see IDE/GCC-ARM)
• Add tests for 3072-bit RSA and DH
• Fixed DRAFT_18 define and fixed downgrading with TLS v1.3

Certificates:

• Alternate certificate chain support with WOLFSSL_ALT_CERT_CHAINS defined enables checking a cert against multiple CA’s
• Fixes to allow custom serial number during certificate generation
• Added method to get WOLFSSL_CTX certificate manager
• Improvement to wolfSSL_SetOCSP_Cb to allow a context per WOLFSSL object
• Updated root certs for OCSP scripts
• Added ASN Extended Key Usage Support. (See wc_SetExtKeyUsage)
• Fix for creation of the KeyUsage BitString

Extensions:

• Added TLS extension for Supported Point Formats (ec_point_formats)
• Fix to not send OCSP stapling extensions in client_hello when not enabled

OCSP Stapling:

• Added new API’s for disabling OCSP stapling
• Add check for SIZEOF_LONG with Sun and LP64

Settings Updates:

• Added new –disable-oldnames option to allow for using openssl alongside wolfssl headers (without OPENSSL_EXTRA)
• Refactor SSL_ and hashing types to use wolf specific prefix (WOLFSSL and WC_) to allow OpenSSL coexistence
• Added configure option for building library for wolfSSH (–enable-wolfssh)
• Added ability to use wolf implementation of strtok using USE_WOLF_STRTOK

MySQL Support:

• Cleanup include paths for MySQL cmake build
• Fix for 8k keys with MySQL compatibility

OpenSSL compatibility:

• OpenSSL compatibility layer improvements, additions, and fixes

Testing:

• Expanded API unit tests
• Update HASH_DRBG Reseed mechanism and add test case
• Added wolfCrypt hash tests for empty string and large data

Hardware Support:

• Fixes for STM32 crypto hardware acceleration
• Fixes for ATECC508A
• Fixes for PIC32MZ hashing
• Fixes and improvements to asynchronous modes for Intel QuickAssist and Cavium Nitrox V

Team wolfSSL is preparing for Halloween with a pumpkin carving! Our embedded security products are continually evolving. We encourage you to check our our wolfSSL embedded SSL/TLS library here, wolfMQTT, wolfSSH, or visit our product page for a complete list of lightweight Open Source security products.

As always if you have any questions, or would like more information about our products, please contact us at facts@wolfssl.com.

Thanks,
Team wolfSSL

It recently came to our attention that the preprocessor macro ALT_ECC_SIZE was missing in our documentation. As a result we decided to post a blog about this to help inform customers of the value for using this in space constrained devices using the fastmath math library with RSA/DH and ECC in wolfSSL.

ALT_ECC_SIZE:

The fastmath code uses an array of a fixed size to store the big integers. By default, the array is big enough for RSA 2048-keys. The FP_MAX_BITS option can be used to make the array smaller if just using ECC. If using both RSA/DH and ECC, the define ALT_ECC_SIZE provides an alternate smaller size for the ecc_point structure. The size can be manually adjusted using FP_MAX_BITS_ECC, otherwise it will be calculated automatically based on the enabled curves.

Without ALT_ECC_SIZE, the ecc_point has three single item arrays of mp_ints for the components of the point. With ALT_ECC_SIZE, the components of the point are pointers that are set to each of a three item array of alt_fp_ints. While an mp_int will have 4096 bits of digit inside the structure, the alt_fp_int will only have 528 bits. A size value was added in the ALT case, as well, and is set by mp_init() and alt_fp_init(). The functions fp_zero() and fp_copy() use the size parameter. An int needs to be initialized before using it instead of just fp_zeroing it, the init will call zero. FP_MAX_BITS_ECC defaults to 528, but can be set to change the number of bits used in the alternate FP_INT.

The ALT_ECC_SIZE option can only be enabled with USE_FAST_MATH.

More details can be found in the wolfssl/wolfcrypt/ecc.h file.

If you have any questions, concerns, comments or feedback please contact us anytime at facts@wolfssl.com or support@wolfssl.com.

A recent paper used wolfSSL as a test bed for proving out their attack on Ed25519 signatures.  You can read the paper here: https://eprint.iacr.org/2017/985.pdf .  This was not an attack on wolfSSL itself or its implementation, but rather a differential power attack that involves SHA-512 and Ed25519.  The recommended countermeasure is to change Ed25519 and remove its deterministic signature properties.  If you are interested in this countermeasure please let us know as we can make this available as a build option.

According to a recent article,  researchers have announced that Wi-Fi security has a protocol level exploit that can render all Wi-Fi traffic vulnerable to sniffing or manipulation. The good news is that if you are already using an independent form of end-to-end encryption such as SSL/TLS then the stolen packets are of little use as they are encrypted independent of the WEP/WPA1/WPA2 protocols.

These vulnerabilities are scheduled to be presented on November 1st at the 24th annual “ACM Conference on Computer and Communications Security” to be held in Dallas, TX.

Paper Title:

     “Key Reinstallation Attacks: Forcing Nonce Reuse in WPA2”

Authors:

     Mathy Vanhoef (KU Leuven, imec-DistriNet)

     Frank Piessens (KU Leuven, imec-DistriNet)

Securing your Wi-Fi traffic with SSL/TLS, offered by @wolfSSL, can keep your data secure in a wireless world by providing independent end-to-end security for your Wi-Fi traffic rendering any stolen Wi-Fi traffic useless to attackers. Users MUST BE AWARE and look for the green lock to ensure the SSL/TLS was not stripped while using Wi-Fi (See video below for explanation!)

PLEASE WATCH THIS VIDEO so you know how to detect if SSL/TLS has been STRIPPED and your traffic is vulnerable to sniffing and/or modification!

An addendum to the report notes that all WPA Supplicant users using v2.6 are vulnerable to this attack (All android 6.0+ users).

References:

https://www.theverge.com/2017/10/16/16481136/wpa2-wi-fi-krack-vulnerability

https://www.theguardian.com/technology/2017/oct/16/wpa2-wifi-security-vulnerable-hacking-us-government-warns

https://www.wired.com/story/krack-wi-fi-wpa2-vulnerability/

https://www.krackattacks.com/

https://acmccs.github.io/session-F3/

https://w1.fi/wpa_supplicant/