RECENT BLOG NEWS

Researchers Clemens Hlauschek, Markus Gruber, Florian Fankhauser, and Christian Schanes of Germany`s Research Industrial Systems Engineering are presenting a TLS Man in the Middle attack at this week’s USENIX conference in Washington D.C: https://www.usenix.org/system/files/conference/woot15/woot15-paper-hlauschek.pdf .  This is a protocol level attack that has a few requirements; a static (EC)DH cipher suite, client authentication with a static (EC)DH private key, and the injection of a known certificate/key pair into the client.  The wolfSSL embedded SSL library does support static ECDH cipher suites, whereas static DH cipher suites are not supported.  While client authentication is supported in wolfSSL ecdsa_fixed_ecdh is not supported, meaning yaSSL / CyaSSL / wolfSSL are not vulnerable to the attack.

We still recommend the use of our max strength build to ensure the highest level of security, max strength ensures Perfect Forward Secrecy cipher suites only: http://www.wolfssl.com/wolfSSL/Blog/Entries/2015/7/10_wolfSSL_Max_Strength_Build.html .  The next release of wolfSSL disables all static cipher suites by default and documents their use as deprecated and insecure as the paper suggests.

Please contact wolfSSL by email at facts@wolfssl.com, or call us at 425 245 8247 if you have any security related questions.

We are pleased to announce that wolfCrypt now has support for SRP6a (Secure Remote Password Protocol version 6a).

SRP is a password authentication and key-exchange protocol suitable for authenticating users and exchanging keys over an untrusted network designed by Thomas Wu at the Computer Science Department of Stanford University.

The SRP implementation can be enabled with either:

./configure –enable-srp

OR

defining WOLFCRYPT_HAVE_SRP if you’re not using autotools.

The wolfCrypt SRP documented api can be found directly in the srp.h file in our repository at github.

If you have any questions about using SRP with wolfCrypt or the wolfSSL embedded SSL/TLS library please let us know at facts@wolfssl.com.

On Thursday, June 11th, Facebook open-sourced a new software development tool called Infer–a next generation static analyzer. Static analysis is the process of using a tool to scan for bugs in source code without actually running a program. Infer has the ability to detect null pointer access errors, as well as resource and memory leaks. Facebook estimates that Infer can catch up to 80% of these errors.

At wolfSSL we were quick to adopt this new opportunity to validate our code, and we ran Infer against the wolfSSL embedded SSL/TLS library codebase. The results were good:

$ inferTraceBugs
No issues found

As you can see, infer did not find any additional errors in wolfSSL`s codebase, giving us one more reason to be confident in the safety and quality of our code.

Going forward, we will integrate Facebook`s Infer into our arsenal of code analysis and testing tools. We run these tools throughout the development cycle to help ensure that we only release the safest possible product.

To read more about infer, visit fbinfer.com.

As stated in the TLS 1.1 and 1.2 protocol definitions (RFC 4346, RFC 5246), “The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications.” TLS 1.2 is an improvement to the TLS 1.1 standard, but how exactly do they differ? What was changed in TLS 1.2 to warrant a new version of the protocol?

Listed below are the changes made to both version 1.1 and 1.2 of the TLS protocol. TLS 1.2 support is making headway in more and more new projects today. The wolfSSL embedded SSL/TLS library fully supports SSL 3.0 (disabled at runtime by default), TLS 1.0, TLS 1.1, and TLS 1.2.

A. TLS 1.1

This protocol was defined in RFC 4346 in April of 2006, and is an update to TLS 1.0. The major changes are:

– The Implicit Initialization Vector (IV) is replaced with an explicit IV to protect against Cipher block chaining (CBC) attacks.
– Handling of padded errors is changed to use the bad_record_mac alert rather than the decryption_failed alert to protect against CBC attacks.
– IANA registries are defined for protocol parameters
– Premature closes no longer cause a session to be non-resumable.

RFC 4346: http://tools.ietf.org/html/rfc4346#section-1.1

A. TLS 1.2

This protocol was defined in RFC 5246 in August of 2008. Based on TLS 1.1, TLS 1.2 contains improved flexibility. One of the primary goals of the TLS 1.2 revision was to remove the protocol’s dependency on the MD5 and SHA-1 digest algorithms. The major differences include:

– The MD5/SHA-1 combination in the pseudorandom function (PRF) was replaced with cipher-suite-specified PRFs.
– The MD5/SHA-1 combination in the digitally-signed element was replaced with a single hash. Signed elements include a field explicitly specifying the hash algorithm used.
– There was substantial cleanup to the client`s and server`s ability to specify which hash and signature algorithms they will accept.
– Addition of support for authenticated encryption with additional data modes.
– TLS Extensions definition and AES Cipher Suites were merged in.
– Tighter checking of EncryptedPreMasterSecret version numbers.
– Many of the requirements were tightened
– Verify_data length depends on the cipher suite
– Description of Bleichenbacher/Dlima attack defenses cleaned up.
– Alerts must be sent in many cases
– After a certificate_request, if no certificates are available, clients now MUST send an empty certificate list.
– TLS_RSA_WITH_AES_128_CBC_SHA is now the mandatory to implement cipher suite.
– Added HMAC-SHA256 cipher suites.
– Removed IDEA and DES cipher suites. They are now deprecated.

RFC 5246: http://tools.ietf.org/html/rfc5246

C. Goals of the TLS Protocol

– Cryptographic security: TLS should be used to establish a secure connection between two parties.
– Interoperability: Independent programmers should be able to develop applications utilizing TLS that can successfully exchange cryptographic parameters without knowledge of one another`s code.
– Extensibility: TLS seeks to provide a framework into which new public key and bulk encryption methods can be incorporated as necessary. This will also accomplish two sub-goals: preventing the need to create a new protocol (and risking the introduction of possible new weaknesses) and avoiding the need to implement an entire new security library.
– Relative efficiency: Cryptographic operations tend to be highly CPU intensive, particularly public key operations. For this reason, the TLS protocol has incorporated an optional session caching scheme to reduce the number of connections that need to be established from scratch. Additionally, care has been taken to reduce network activity.

Resources:
If you would like to read more about SSL or TLS, here are several resources that might be helpful:
wolfSSL Manual (https://www.wolfssl.com/wolfSSL/Docs-wolfssl-manual-toc.html)
TLS – Wikipedia (http://en.wikipedia.org/wiki/Transport_Layer_Security)
SSL vs TLS – What`s the Difference? (http://luxsci.com/blog/ssl-versus-tls-whats-the-difference.html)
Cisco – SSL: Foundation for Web Security (http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_1-1/ssl.html)

If you have any questions or would like to talk to the wolfSSL team about more information, please contact facts@wolfssl.com.

wolfSSL, in partnership with Security Innovation, has added support for the proposed “Quantum-safe hybrid” ciphersuite. Having this cipher suite supported in the wolfSSL embedded TLS library allows two parties to use any existing ciphersuite and “quantum-safe” any traffic protected by that ciphersuite. This means that an attacker who records the traffic and later develops a quantum computer cannot go back and crack the session.

The super-fast NTRU algorithm, featuring efficient key generation, encryption, and decryption, is a quantum computer resistant algorithm currently being used with the quantum-safe ciphersuite. By using a one-time NTRU key to encrypt extra secret material, the handshake allows users to continue using their existing ciphersuites (which may be necessary for certificate support or because they have regulations that require it) while at the same time benefiting from the true long-term security that NTRU gives. Because NTRU is fast, the additional processing load from the use of this ciphersuite is low. The ciphersuite is provably as secure as classical ciphersuites. Users can use it without concern that it is reducing their security, making this genuinely a zero-risk, near-zero-cost approach to obtaining protection against government or other actors, now and in the future.

“We`re excited to continue our partnership with wolfSSL and applaud wolfSSL`s vision in being first to market with this innovative, future-proof approach,” said William Whyte, Chief Scientist at Security Innovation. “wolfSSL has a name for being best in the field for embedded devices; with this approach, WolfSSL is enabling their customers to protect data on any device, not just now but for years to come.”

To view and use the quantum safe handshake extensions first download and install NTRU (which an Open Source version can be found at https://github.com/NTRUOpenSourceProject/ntru-crypto) then download the most recent wolfSSL from GitHub ( https://github.com/wolfSSL/wolfssl ) and compile using ./configure –with-ntru. The QSH ciphersuite specification will be available from the IETF website the week of July 19th. A security proof for the approach is provided in https://eprint.iacr.org/2015/287.

For more information about the implementation or use contact wolfSSL at facts@wolfssl.com

wolfSSL (formerly CyaSSL) recently added a build option called “Max Strength”. This build option forces most cipher suites to be disabled at compile time to prevent their accidental use during run time. Options such as MD5, 3DES, and ARC4 are left out of the build completely.

The cipher suites that are enabled by default have Perfect Forward Security (PFS) and Authenticated ciphers (AEAD). The remaining suites have the AEAD ciphers including at least one of AES-GCM, AES-CCM, or CHACHA-POLY1305; ECDHE or DHE; ECDSA or RSA; SHA-256 and SHA-384. The minimum allowed DHE key bit-size is set to 2048 bits.

To enable the maximum strength build with wolfSSL, on the configure command line add the option “–enable-maxstrength”, or add “#define WOLFSSL_MAX_STRENGTH” to your settings.h file.

OpenSSL released a security advisory on July 9th 2015: https://www.openssl.org/news/secadv_20150709.txt .  Some wolfSSL embedded TLS users are probably wondering if similar security fixes are required in wolfSSL.  The answer to that is no.  Specifically, Alternative chains certificate forgery (CVE-2015-1793) is an OpenSSL implementation bug.  Faulty logic allowed untrusted certificates to appear as trusted.  Since wolfSSL, CyaSSL, and yaSSL embedded SSL libraries have a completely different code base from OpenSSL we do not share this defect.

Please contact wolfSSL by email at info@wolfssl.com, or call us at 425 245 8247 if you have any security related questions.

Hi!  As many of our users know, we use Zendesk to track our support tickets.  Zendesk includes some sweet tools that we enjoy, including an automated user satisfaction tool.  The tool surveys users after they have submitted a support case to us.  Upon review of our support statistics for the first half of this year, we were pleased to find that 100% of our users who completed our satisfaction survey are happy!
  
Our response times and resolution times were also ahead of benchmarks.

This note is also an opportunity to remind our open source users out there that wolfSSL support for open source projects is 100% available, and still 100% free.  Just let us know how we can help.  If you need support, new features or enhancements, you are always welcome to email us at facts@wolfssl.com, or call us at +1 425 245 8247.

For those who want to use wolfCrypt separately to do cryptography operations, we are happy to announce that the first version of the wolfCrypt API documentation is now available. The wolfCrypt API Reference is available to browse online and also available for download in PDF format.

Link: wolfCrypt API Reference

wolfCrypt has a broad range of support for current and progressive algorithms as well as support for a number of different hardware crypto modules.

Please contact us at facts@wolfssl.com with any questions.

If working on a memory constrained device we now have memory optimized Ed25519 and Curve25519 options. This can be enabled with using the configure setting “./configure –enable-ed25519=small –enable-curve25519=small –enable-sha512”.

The new feature allows for a trade off in memory usage versus speed. All of the operations in the memory optimized build, except for SHA-512, use types that are equal to or less than 32 bits in size. On a Raspberry Pi the size of Ed25519 and Curve25519 is just under 18k for the memory optimized build versus 83k for the standard. The trade off for less memory does come at a hit to run time but for use cases that don`t generate many keys and have very little memory to work with this is a great option.

For more info please contact us at facts@wolfssl.com.