RECENT BLOG 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.
If you are a user of the popular MacPorts project on OS X, you may be happy to hear that the wolfSSL embedded SSL library is now available as a MacPorts package. If you are not familiar with the MacPorts Project, a brief summary from their website does an excellent job of explaining the project. At the time this post was written, there were 15,657 ports in the MacPorts tree.
As stated on their homepage, “The MacPorts Project is an open-source community initiative to design an easy-to-use system for compiling, installing, and upgrading either command-line, X11 or Aqua based open-source software on the Mac OS X operating system. To that end we provide the command-line driven MacPorts software package under a BSD License, and through it easy access to thousands of ports that greatly simplify the task of compiling and installing open-source software on your Mac.
We provide a single software tree that attempts to track the latest release of every software title (port) we distribute, without splitting them into “stable” Vs. “unstable” branches, targeting mainly the current Mac OS X release (10.8, A.K.A. Mountain Lion) and the immediately previous two (10.7, A.K.A. Lion and 10.6, A.K.A. Snow Leopard).”
To install the wolfSSL MacPorts package on OS X, there are only a few simple steps required:
1. Download and install MacPorts (http://www.macports.org/install.php)
2. From the OS X terminal, run the command, “sudo port install cyassl”. This will install wolfSSL into the /opt/local directory.
To learn more about MacPorts, please visit their website at www.macports.com.
As you may know, CTaoCrypt is the underlying cryptography library used by the wolfSSL embedded SSL library. We’ve had several users choose to use CTaoCrypt’s crypto algorithms because they are easy to isolate and use independently of the library itself. For example, if you need to use MD5 in your own code but don’t want to write it yourself, you could extract CTaoCrypt’s MD5 implementation and use it directly in your code.
Most crypto algorithms in CTaoCrypt are contained within a source file and header file. For MD5, the relevant code would be in ./cyassl/ctaocrypt/md5.h and ./ctaocrypt/src/md5.c. Other algorithms follow the same directory and source file pattern.
If you have any questions about using CTaoCrypt’s algorithms separately, please let us know at firstname.lastname@example.org. As always, feel free to download the GPLv2-licensed source code for wolfSSL/CTaoCrypt directly from our download page and try it out for yourself.
The third release of the yaSSL Embedded Web Server is now available for download! Changes in this release include bug fixes, updated wolfSSL support, iOS (Apple TV) build support, better Windows build support, CGI and SSI extension pattern matching and more.
The yaSSL Embedded Web Server is focused on being small, fast, and embeddable. Features include CGI, SSI, IP restrictions, access and error log support, and SSL among others. The wolfSSL embedded SSL library can be used to easily secure ports with SSL/TLS up to TLS 1.2, giving you a secure connection while maintaining small size and fast speed.
If you have any questions, or would like to learn more about the yaSSL Embedded Web Server and how it can help your project, please contact email@example.com.
Hi! We`ve had recent requests for SNI in wolfSSL. SNI is well documented on wikipedia here: http://en.wikipedia.org/wiki/Server_Name_Indication.
If you are interested in using SNI with wolfSSL, then please contact us and let us know. We may be able to add you to our beta list. Contact us at firstname.lastname@example.org
Version 2.3.0 of the wolfSSL embedded SSL/TLS library has been released and is now available for download. This release contains bug fixes and new features. Changes include the following (with details and comments for each listed below):
– AES-GCM crypto and cipher suites
– “make test” cipher suite checks
– Subject AltName processing
– Command line support for client/server examples
– Sniffer SessionTicket support
– SHA-384 cipher suites
– Verify cipher suite validity when user overrides
– CRL directory monitoring
– DTLS Cookie support, reliability coming soon
The addition of AES-GCM (Galois/Counter Mode) cryptography and cipher suites brings the wolfSSL embedded SSL library one step away from being NSA Suite B compliant. The one missing element is ECC – which wolfSSL will be getting in September 2012.
wolfSSL 2.3.0 offers four different implementations of AES-GCM balancing speed versus memory consumption. If available, wolfSSL will use 64-bit or 32-bit math. For embedded applications, there is a speedy 8-bit version that uses RAM-based lookup tables (8KB per session) which is speed comparable to the 64-bit version and a slower 8-bit version that doesn`t take up any additional RAM. To enable AES with GCM in wolfSSL, configure the build with the option “–enable-aesgcm”. The configure option may be modified with the options “=word32”, “=table”, or “=small”, i.e. “–enable-aesgcm=table”.
“make test” Cipher Suite Checks
With the last few releases of wolfSSL, we’ve been working on enhancing wolfSSL’s default test cases which are executed when “make test” is issued from the wolfSSL root directory. With this release, we have added test cases for wolfSSL’s ciphers suites. The cipher suite checks iterate through wolfSSL’s SSL 3.0, TLS 1.0, 1.1, and 1.2 cipher suites (as defined in the /tests/test.conf file), verifying that each suite works correctly. When running “make test” you will now see output similar to the following for each cipher suite tested:
# server SSLv3 RC4-SHA
# client SSLv3 RC4-SHA
trying server command line: SuiteTest -v 0 -l RC4-SHA
trying client command line: SuiteTest -v 0 -l RC4-SHA
Client message: hello cyassl!
Server response: I hear you fa shizzle!
Subject AltName Processing
An X.509 certificate may contain a Subject Alternative Name, or “subjectAltName” extension which allows identities to be bound to the subject of the certificate. These names might be included in addition to the existing name in the Subject field of an X.509 certificate, or they may included in place of the standard Subject field of the certificate. Subject Alternative Names may take a variety of formats including an email address, DNS name, IP address, or a URI. This extension is defined in Section 184.108.40.206 of RFC 5280 (http://tools.ietf.org/html/rfc5280).
With this release, wolfSSL now processes Subject Alternative Names in certificates. wolfSSL has a new API function, wolfSSL_X509_get_next_altname() which allows retrieval of the subjectAltNames that have been processed.
Command Line Support for client/server Examples
The wolfSSL example client and server can now be run from the command line with a number of different options. These options allow users to select the Host, Port, SSL version, cipher list, certificate file, key file, CA file, toggle DTLS and pre shared keys, and more. To see the available options, run either ./examples/client/client or ./examples/server/server with the “-?” option:
The available options will be listed, similar to:
client 2.3.0 NOTE: All files relative to wolfSSL home dir
-? Help, print this usage
-s Use pre Shared keys
-d Disable peer checks
-g Send server HTTP GET
-u Use UDP DTLS
-m Match domain name in cert
Sniffer SessionTicket Support
wolfSSL’s Sniffer (or Inspection) functionality has been made more robust by the addition of support for TLS Session Tickets. The SessionTicket TLS extension is defined in RFC 5077 (http://tools.ietf.org/html/rfc5077). This extension enables a TLS server to resume sessions without storing per-client session information on the server side. The server encapsulates the current session state for a specific client into a ticket and forwards it to the client. That client is then able to resume a session if needed by using the previously-obtained ticket from the server.
SHA-384 Cipher Suites
With the addition of GCM support to wolfSSL, we have also added a number of SHA-384 cipher suites. New SHA-384 suites include:
Verify Cipher Suite Validity when User Overrides
wolfSSL 2.3.0 now checks to make sure that certificates and keys loaded into wolfSSL are valid for specified cipher suites chosen by the user. This added check enhances wolfSSL’s robustness and will prevent errors some users see when hand-picking cipher suites to use while not having all the correct functionality built into wolfSSL.
CRL Directory Monitoring
As you may know, we added initial support for CRL (Certificate Revocation List) with the release of wolfSSL 2.2.0 in May of this year. With this 2.3.0 release, we have added the ability to have wolfSSL actively monitor a specific CRL directory. Example usage can be seen in the wolfSSL example server (./examples/server/server.c) inside of the HAVE_CRL defines:
wolfSSL_LoadCRL(ssl, crlPemDir, SSL_FILETYPE_PEM, CYASSL_CRL_MONITOR |
DTLS Cookie Support
wolfSSL has had DTLS support for quite some time, but we’re currently working on making it more functional and robust. With this release, wolfSSL’s DTLS implementation now supports cookies. Cookies are used in DTLS to prevent denial of service attacks. As stated in section 4.2.1 of RFC 4347 (http://tools.ietf.org/html/rfc4347):
“Datagram security protocols are extremely susceptible to a variety of denial of service (DoS) attacks. Two attacks are of particular concern:
• An attacker can consume excessive resources on the server by transmitting a series of handshake initiation requests, causing the server to allocate state and potentially to perform expensive cryptographic operations.
• An attacker can use the server as an amplifier by sending connection initiation messages with a forged source of the victim. The server then sends its next message (in DTLS, a Certificate message, which can be quite large) to the victim machine, thus flooding it.
In order to counter both of these attacks, DTLS borrows the stateless cookie technique used by Photuris (http://tools.ietf.org/html/rfc4347#ref-PHOTURIS) and IKE (http://tools.ietf.org/html/rfc4347#ref-IKE). When the client sends its ClientHello message to the server, the server MAY respond with a HelloVerifyRequest message. This message contains a stateless cookie generated using the technique of Photuris. The client MUST retransmit the ClientHello with the cookie added. The server then verifies the cookie and proceeds with the handshake only if it is valid. This mechanism forces the attacker/client to be able to receive the cookie, which makes DoS attacks with spoofed IP addresses difficult. “
We’re currently working on adding reliability to our DTLS implementation. This should be rolling out in the near future, so keep an eye on our blog for more news!
To download the open source, GPLv2-licensed version of wolfSSL 2.3.0, please visit our Download Page. If you have any questions or comments or would like more information on commercial versions of wolfSSL, please contact us at email@example.com.
For build instructions, a full feature list, API reference, and more, please see the wolfSSL Manual.
Hi! As you may know, we`ve released our GCM code recently. Our next major open source release, coming in September, will include our ECC implementation. This will bring wolfSSL into Suite B compliance. If you need our ECC code before our next release, just contact us at firstname.lastname@example.org and we`ll get it into your hands.
We have added the Galois/Counter Mode for AES to wolfSSL. It adds an Authenticated Data with Associated Data (AEAD) cipher to TLS v1.2 where the cipher provides its own message authentication. The following cipher suites are available:
We offer four different implementations balancing speed versus memory consumption. If available, it will use 64-bit or 32-bit math. For embedded SSL applications, there is a speedy 8-bit version that uses RAM-based lookup tables (8KB per session) that is speed comparable to the 64-bit version and a slower 8-bit version that doesn`t take up any additional RAM.
AES with GCM will be available in our next release. The latest sources are available in our GitHub repository. To enable AES with GCM in wolfSSL, configure the build with the option “–enable-aesgcm”. The configure option may be modified with the options “=word32”, “=table”, or “=small”, i.e. “–enable-aesgcm=table”.
We are very excited to offer this new cipher. Adding AES with GCM makes wolfSSL compatible with NSA Suite B.
yaSSL has released a new case study highlighting how one of our customers, CCww, is using the wolfSSL embedded SSL library to secure GSM / GPRS modem modules. This case study highlights the key requirements CCww had for securing their modules, how wolfSSL was used as a solution, and summarizes CCww’s thoughts on the project.
You can download the case study directly from the yaSSL website at the following location. If you have any questions about using wolfSSL to secure your project, please contact us at email@example.com.
yaSSL / CCww Case Study: http://www.yassl.com/files/casestudy/casestudy_yassl_ccww.pdf
We wanted to remind our readers to enter our sweepstakes for a chance to win a New Apple iPad (16GB, Wi-Fi). The sweepstakes will be coming to a close August 1, 2012 (just 9 days away!). For a chance to win, just take our short SSL survey (10 questions) at the following link. The contest is limited to one entry per individual.
Begin the survey, here: http://www.surveymonkey.com/s/585N8LZ (this survey has been closed)
Eligibility: To be eligible to win you must be a legal resident of the fifty (50) United States or the District of Columbia and be at least eighteen (18) years old at the time of entry.
We appreciate your time and feedback! All results and comments will be taken into consideration to improve our products. If you have any questions, please email us at firstname.lastname@example.org.
As the first post in our PKCS series, we will be looking at PKCS #1. PKCS #1 is the RSA Cryptography Standard and is defined in RFC 3447 (http://tools.ietf.org/html/rfc3447). It defines standards for implementing public and private keys based on the RSA algorithm including cryptographic primitives, encryption schemes, signature schemes, and ASN.1 syntax for representing the keys and identifying the schemes.
A. Cryptographic Primitives
As stated in the RFC, cryptographic primitives are “basic mathematical operations on which cryptographic schemes can be built. Four different types of cryptographic primitives are defined in PKCS #1: encryption, decryption, signature, and verification.
An encryption primitive produces a ciphertext from a plaintext under the control of a public key. A decryption primitive produces a plaintext from a ciphertext under the control of a corresponding private key. PKCS #1 defines one pair of encryption/decryption primitives, specified as RSAEP and RSADP in RFC 3447, with exponentiation being the main mathematical operation used.
A signature primitive produces a signature from a message under the control of a private key. A verification primitive recovers the message from the signature under the control of the corresponding public key. The specific primitives defined for signature and verification in PKCS #1 are RSASP1 and RSAVP1.
B. Encryption and Signature Schemes
As stated in RFC 3447, “a scheme combines cryptographic primitives and other techniques to achieve a particular security goal.” The two types of schemes defined in PKCS #1 are encryption schemes and signature schemes with appendix. The schemes presented in PKCS #1 are limited in that they only present methods to process data with either a public or private key. They do not include any type of recommendations or steps to handle key management.
Both encryption schemes and signature schemes can be applied in many situations. One example given in RFC 3447 regarding an encryption scheme is usage in a key establishment protocol, where the message contains key material that needs to be delivered from party A to party B confidentially. An example given by the RFC for signature scheme usage could be as a signature algorithm for X.509 certificates. Note that signature schemes with appendix (defined in PKCS#1) are different than signature schemes with message recovery.
C. ASN.1 Syntax
The last item which is defined in PKCS #1 is ASN.1 object identifiers for RSA public and private keys and the RSA public and private key structure. The intended applications of these definitions include X.509 certificates, PKCS #8, and PKCS #12.
The wolfSSL embedded SSL library uses the PKCS #1 standard for RSA public and private keys and RSA operations. For example, if you examine the code, you can see how wolfSSL’s RsaKey type (./cyassl/ctaocrypt/rsa.h) matches up to the RSA key definition in PKCS #1.
To learn more about PKCS #1, you can look through RFC 3447, here:
To learn more about the wolfSSL embedded SSL library, you can download a free GPLv2-licensed copy from the yaSSL download page, https://www.wolfssl.com/download/, or look through the wolfSSL Manual, http://www.yassl.com/yaSSL/Docs-cyassl-manual-toc.html. If you have any additional questions, please contact us at email@example.com.
- December 2019 (2)
- November 2019 (16)
- October 2019 (14)
- September 2019 (24)
- August 2019 (21)
- July 2019 (8)
- June 2019 (13)
- May 2019 (35)
- April 2019 (32)
- March 2019 (20)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (11)
- October 2018 (18)
- September 2018 (18)
- August 2018 (8)
- July 2018 (15)
- June 2018 (29)
- May 2018 (15)
- April 2018 (11)
- March 2018 (19)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (7)
- September 2017 (8)
- August 2017 (6)
- July 2017 (11)
- June 2017 (8)
- May 2017 (10)
- April 2017 (5)
- March 2017 (7)
- February 2017 (1)
- January 2017 (8)
- December 2016 (3)
- November 2016 (2)
- October 2016 (18)
- September 2016 (8)
- August 2016 (5)
- July 2016 (4)
- June 2016 (11)
- May 2016 (4)
- April 2016 (5)
- March 2016 (4)
- February 2016 (12)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (6)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (13)
- January 2015 (6)
- December 2014 (7)
- November 2014 (3)
- October 2014 (2)
- September 2014 (11)
- August 2014 (6)
- July 2014 (9)
- June 2014 (11)
- May 2014 (11)
- April 2014 (9)
- March 2014 (3)
- February 2014 (3)
- January 2014 (5)
- December 2013 (9)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (8)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (9)
- December 2012 (13)
- November 2012 (5)
- October 2012 (7)
- September 2012 (4)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (6)
- April 2012 (7)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (6)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (8)
- May 2011 (12)
- April 2011 (4)
- March 2011 (12)
- February 2011 (9)
- January 2011 (13)
- December 2010 (17)
- November 2010 (12)
- October 2010 (14)
- September 2010 (11)
- August 2010 (20)
- July 2010 (14)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)