RECENT BLOG NEWS

So, what’s new at wolfSSL? Take a look below to check out the most recent news.
Or sign up to receive weekly email notifications containing the latest news from wolfSSL.
In addition, wolfSSL now has a support-specific blog page dedicated to answering some of the more commonly received support questions.

wolfSSL + Nginx

The wolfSSL embedded SSL/TLS library provides support for various open source projects, including Nginx. For those who are unfamiliar, Nginx is a high-performance, high-concurrency web server. Like wolfSSL, it is also compact, fast, and highly scalable. Additionally, wolfSSL also provides support for TLS 1.3 and features such as OCSP, so Nginx servers can be configured with the latest and most secure protocols.

Nginx and wolfSSL make a likely pairing because they are both lean, compact, fast, and scale well under high volumes of connections. wolfSSL + Nginx is available in a public GitHub repository.  The configure option --enable-nginx will compile the wolfSSL libraries with Nginx support.

wolfSSL also provides FIPS and FIPS ready versions of the wolfCrypt library, meaning Nginx can be built FIPS compliant. More information on wolfCrypt FIPS can be found on the wolfCrypt FIPS FAQ page.

For more information on wolfSSL + Nginx, TLS 1.3, OCSP, FIPS, or for any additional questions, contact facts@wolfssl.com.

What is Online Certificate Status Protocol (OCSP)

Online Certificate Status Protocol or OCSP is an Internet protocol that is used to obtain the revocation status of an X.509 digital certificate. An OCSP client will send a status request to an OCSP responder and receive information if the certificate is valid or revoked. A good response shows that the certificate is valid and not revoked. Messages communicated via OCSP are encoded in ASN.1, a set of notations that describe rules and structures in telecommunications and networking, and are usually communicated over HTTP. The OCSP servers are called OCSP responders because of the request/response nature of the transmission between them and the client.

It was created as an alternative to Certificate Revocation Lists (CLR) for maintaining the security of servers and other network resources. It hoped to address certain problems regarding the use of CRLs in public key infrastructure (PKI). OCSP has many advantages over CRL. It overcomes CRL’s prime limitation: the fact that frequent downloads are required to keep things current at the client’s side. OCSP also can provide more timely information regarding the revocation status of a certificate. It also removes the need for clients to retrieve the CRL themselves (better bandwidth management), as well as the fact that OCSP allows users with an expired certificate a grace period (decreasing any downtime with expired certificates).

For this exact reason we added OCSP as a wolfSSL feature back in 2011. In our new release wolfSSL 4.3.0 we have added additional sanity check on OCSP response decoders.

If you have questions about our OCSP support, email us at facts@wolfssl.com.  wolfSSL supports TLS 1.3, FIPS 140-2, DO-178, and more!

We love you,
wolfSSL Team

wolfSSL MSU Info Session

Are you a MSU Bozeman student interested in the field of Internet security?  If so, wolfSSL will be holding an info session this upcoming Thursday (2/13/2020) at Montana State University in Bozeman, MT!  This info session will introduce wolfSSL as a company, including background information, products, work environment, and summer internship opportunities.  It will also touch on new technologies, such as TLS 1.3!

wolfSSL is an open source Internet security company focused on securing connected devices and applications worldwide!  wolfSSL products include the wolfSSL lightweight SSL/TLS library, wolfCrypt cryptography library, wolfSSH SSH library, wolfMQTT, wolfTPM, and more!

We encourage all students who are interested in Internet security, SSL/TLS, cryptography, embedded security, or software development to attend! Pizza will be served!

wolfSSL Info Session
Thursday, February 13, 2020
Norm Asbjornson Hall, room 149
Montana State University, Bozeman

We look forward to seeing you there! Please contact chris@wolfssl.com with any questions or for more information. To learn more about the wolfSSL lightweight SSL/TLS library, visit our product page or GitHub repository today!

wolfSSL + Apache httpd

In the latest wolfSSL releases, we have added 200+ new API to our OpenSSL compatibility layer. Many of these new API were added for providing support for Apache HTTP Server.

We are excited to announce that as of version 4.3.0, wolfSSL provides support for the Apache web server with the enable option –enable-apachehttpd.  This means you can now build Apache with the latest, most robust security provided by the wolfSSL SSL/TLS and wolfCrypt libraries.  wolfSSL supports TLS 1.3, FIPS 14-2, DO-178, and more!

If you are interested in building Apache httpd with wolfSSL, please contact us at facts@wolfssl.com for a version of Apache that is compatible.

For comparison between wolfSSL and OpenSSL, visit https://www.wolfssl.com/docs/wolfssl-openssl/.

We love you,
wolfSSL Team

How to use TLS with JAVA

When developing an application that needs to communicate securely with another device TLS is a great option. The framework in place for TLS connections with JAVA is JSSE (Java Secure Socket Extension). JSSE is a set of interfaces that can be called to abstract the TLS process and make it easy for plugging in different security providers while keeping an application unchanged after initial integration. wolfJSSE is an open source implementation of these interfaces that uses the embedded IoT wolfSSL library for it’s cryptography operations. There are many ways to interact with JSSE when adding in security, two of the common ways are with creating a SSL socket or by creating a SSL engine. A simple example of creating and using SSL sockets for both the client and server side can be found in the “examples/provider” directory on the wolfssljni repository located here (https://github.com/wolfSSL/wolfssljni). In addition to interacting with JSSE directly there are packages in JAVA that use it. One such package deals with URL connections and can be used for creating HTTPS connections. An example of a simple HTTPS connection using it can be found in the “java” directory of the wolfSSL examples repository (https://github.com/wolfSSL/wolfssl-examples).

For questions about the use of wolfJSSE, or the wolfSSL lightweight SSL/TLS library, contact facts@wolfssl.com.

Improved NXP MMCAU Crypto Hardware Performance

The NXP Memory-Mapped Cryptographic Acceleration Unit (mmCAU) is on many Kinetis microcontrollers. It improves symmetric AES and SHA performance as compared to our software based implementation. wolfSSL version 4.2.0 enhanced mmCAU support to use multiple blocks against hardware and optimize to avoid memory copies (memcpy) when possible. This resulted in a 20-78% improvement in performance!

Features:

  • Enhancement for NXP mmCAU to process more than one block at a time.
  • Added optional buffer alignment detection macro, WC_HASH_DATA_ALIGNMENT, to avoid memcpy.
  • Added MD5 and SHA-1 support for XTRANSFORM_LEN to process blocks.
  • Cleanups for consistency between algorithms and code commenting.

Improved MMCAU performance: SHA-1 by 35%, SHA-256 by 20% and MD5 by 78%.

NXP K64 MMCAU with wolfSSL v4.2.0:

MD5 8 MB took 1.000 seconds, 7.910 MB/s
SHA 4 MB took 1.005 seconds, 3.644 MB/s
SHA-256 2 MB took 1.006 seconds, 2.306 MB/s

NXP K64 MMCAU with wolfSSL v4.1.0:

MD5 4 MB took 1.004 seconds, 4.450 MB/s
SHA 3 MB took 1.006 seconds, 2.670 MB/s
SHA-256 2 MB took 1.008 seconds, 1.913 MB/s

Changes are in GitHub pull request #2481 and in the wolfSSL v4.3.0 release.
For more information please email us at facts@wolfssl.com.

We love you,
wolfSSL Team

CMS/PKCS #7 RSA Sign Callback for Raw Digest Signature Generation

We have added many new features in our new release of wolfSSL 4.3.0. One new feature we have added is a CMS/PKCS #7 callback for signing SignedData raw digests – enabled with the macro HAVE_PKCS7_RSA_RAW_SIGN_CALLBACK and call to function wc_PKCS7_SetRsaSignRawDigestCb().

For those who are unaware PKCS #7 is used to sign and/or encrypt messages under a PKI. Used also for certificate dissemination (for instance as a response to a PKCS #10 message), it formed the basis for S/MIME, which is as of 2010 based on RFC 5652, an updated Cryptographic Message Syntax Standard (CMS). Often used for single sign-on.

For more information on wolfSSL, PKCS #7, TLS 1.3, OCSP, FIPS, or for any additional questions, contact facts@wolfssl.com or support@wolfssl.com!

We love you.

Team wolfSSL

Updates to RSA-PSS salt lengths

In our new release of wolfSSL 4.3.0 we have added updates to RSA-PSS salt lengths. The macro WOLFSSL_PSS_SALT_LEN_DISCOVER value into wc_RsaPSS_Verify_ex() attempts to discover salt length and can use larger salt lengths.

RSA-PSS is a probabilistic signature scheme (PSS) with appendix. A signature scheme with appendix requires the message itself to verify the signature (i.e. the message is not recoverable from the signature). RSA-PSS is an adaptation of their work and is standardized as part of PKCS#1 v2.1. In general, RSA-PSS should be used as a replacement for RSA-PKCS#1 v1.5.

RSA-PSS parameters

  • hash algorithm/function. The default is SHA-1.
  • mask generation function (MGF). Currently always MGF1.
  • salt length. The default value is 20 but the convention is to use hLen, the length of the output of the hash function in bytes. A salt length of zero is permitted and will result in a deterministic signature value. The actual salt length used can be determined from the signature value.
  • trailer field, used in the encoding operation. The default trailer field is the byte 0xbc. There are no options to change this value.

The default parameters for RSA-PSS are:

hashAlgorithm      sha1,
maskGenAlgorithm   mgf1SHA1 (the function MGF1 with SHA-1)
saltLength         20,
trailerField       trailerFieldBC (the byte 0xbc)

It is recommended that the MGF hash function be the same as the scheme hash algorithm/function, and that the salt length be hLen, the length of the output of the hash function.

For more information on RSA-PSS visit https://www.cryptosys.net/pki/manpki/pki_rsaschemes.html

For more information on wolfSSL updates, TLS 1.3, OCSP, FIPS 140-2, or for any additional questions, contact facts@wolfssl.com or support@wolfssl.com!

We love you.

Team wolfSSL

Check out our Webinar on TLS 1.3, OpenSSL COMPARISON!

wolfSSL: TLS 1.3, OpenSSL comparison

wolfSSL’s open-source SSL/TLS library is constantly updated to maintain a mature code base and adapts quickly to any standard changes. One recent change is the release of TLS 1.3 (successor of TLS 1.2 which was out for 10 years).

What is new in TLS 1.3?
TLS 1.3 brought forth numerous improvements including faster handshake times, full session encryption and new cipher suites. There are faster handshake times as there is only one RTT instead of two which enables clients to send data immediately after the first reply from the server. Full session encryption is also achieved through the use of a variety of encryption algorithms to secure data. In addition, new cipher suites considered to be stronger also come with TLS 1.3.

How are we different from OpenSSL?
There are several key differentiators between wolfSSL and OpenSSL. These include the following:

  • Build size (up to 20x smaller than OpenSSL)
  • Standards support: up to date on most recent standards
  • Hardware acceleration
  • Team of security experts
  • Ease of Use designed for developers
  • Portability: a long list of supported platforms
  • Dual license: GPLv2 or Commercial
  • 24/7 Support

To watch all the wolfSSL webinars, check out our YouTube channel:
https://www.youtube.com/channel/UCxcGPWzOnhdocvKmxqhfvPg?view_as=subscriber

To read more about the differences between TLS 1.2 and TLS 1.3 visit:
https://www.wolfssl.com/differences-between-tls-12-and-tls-13-12/

Questions? Contact us facts@wolfSSL.com

wolfMQTT Client Supports Secure AWS

The wolfMQTT client library has an Amazon Web Services example that demonstrates securely connecting over TLS provided by the wolfSSL embedded SSL/TLS library.

We setup an AWS IoT endpoint and testing device certificate. The AWS server uses a TLS client certificate for authentication. The example is located in `/examples/aws/`.  It subscribes to `$aws/things/”AWSIOT_DEVICE_ID”/shadow/update/delta` and publishes to `$aws/things/”AWSIOT_DEVICE_ID”/shadow/update`.

Everyone deserves to have their IoT data secure, and wolfSSL provides the best libraries to accomplish that! wolfSSL supports up to TLS 1.3, FIPS 140-2, expansive support for hardware cryptography, and more!  Secure-IoT-Love from the wolfSSL team!

You can download the latest release here: https://www.wolfssl.com/download/

Or clone directly from our GitHub repository.

Don’t forget to add a star while you’re there!  Contact us at facts@wolfssl.com with any questions or comments.

Posts navigation

1 2 3 4 5 6 109 110 111

Weekly updates

Archives

Latest Tweets