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.
Here`s the fourth part in a four part series giving a more detailed report on some of the new features present in the recent wolfSSL release.
• Shared build only by default. wolfSSL used to build in shared mode and static mode by default, somewhat handy, but twice as time consuming. Now, wolfSSL will only build in shared mode by default, seemingly speeding up the build by a factor of two. Of course either mode can still be explicitly disabled or enabled.
• Compiler visibility additions. wolfSSL now uses compiler visibility, if the compiler supports it, to explicitly expose or hide non static functions. This decreases wolfSSL`s pollution of the global namespace and also decreases the chance of collisions.
• Single Makefile. wolfSSL used to use Makefiles recursively, one for each directory. While initially easy to setup, there are several drawbacks to this configuration including slow build times and increasingly complex interactions between the files. The new single makefile is simpler and faster. Thanks to Brian Aker for suggesting the last two items.
• Kitchen sink warnings. wolfSSL now has a configure option (–enable-gcc-lots-o-warnings) that turns on many additional warnings that shouldn`t fire in a release. wolfSSL has removed the ones that do, though not all systems, versions, compiler versions have been tested so we`re still fine-tuning these.
June 8, 2011 (this Wednesday) is World IPv6 Day, a day that several major organizations will offer content over IPv6 during a 24-hour time period. As stated on the ISOC website, “the goal of the test flight day is to motivate organizations across the industry – Internet service providers, hardware makers, operating system vendors and web companies – to prepare their services for IPv6 to ensure a successful transition as IPv4 addresses run out.”
Organizations who are taking part in World IPv6 Day include Google, Facebook, Yahoo, Akamai, Limelight Networks, CISCO, Comcast, and many more. You can find the entire list of stated participants here, http://www.worldipv6launch.org/participants/.
wolfSSL has support for IPv6 as well! wolfSSL was designed as IP neutral, and will work with both IPv4 and IPv6. The test applications included in the wolfSSL download currently default to using IPv4 (to apply to a broader number of systems). In order to change the test applications to use IPv6, use the –enable-ipv6 option while building the wolfSSL embedded SSL library.
Are you prepared for IPv6 Day? To test your current browser setup for World IPv6 Day, you can visit the following pages (which will run a test on your browser setup):
To learn more about IPv6 in general, visit the Wikipedia page, here: http://en.wikipedia.org/wiki/IPv6. As always, if you have questions or comments about the wolfSSL embedded SSL library or the yaSSL Embedded Web Server, please let us know at email@example.com.
The 2nd and possible final release candidate for wolfSSL 2.0 is now available. This release contains bug fixes for Alert processing and DTLS with DHE. New features include:
– FreeRTOS support
– lwIP support
– Wshadow warnings removed
– ctc_ prefix for CTaoCrypt headers (manual still being updated for this)
– asn public header for better collision avoidance
Stay tuned for more detailed explanations of the new features that haven`t been covered in our blog series yet. For questions or comments about this release or embedded SSL in general please contact the yaSSL team at firstname.lastname@example.org.
Ivan Risti?, Director of Engineering at Qualys, Inc., will be presenting the results of the first publicly-available survey aimed at assessing the state of SSL on the Internet. His results will be presented through a free webcast on June 22, 2011 at 2:00 PM EDT. The presentation will also provide documentation and free tools to test and improve the configuration on SSL servers. If you are interested in listening to SSL Labs` results, you can register for the free webcast using the following link.
Qualys SSL Labs: https://www.ssllabs.com/
One of the services that yaSSL provides is the wolfSSL Competitive Upgrade Program. With this program, yaSSL offer competitive upgrade pricing for those who wish move from an outdated or expensive SSL library to wolfSSL with low cost and minimal disturbance to their code base.
Here’s an outline of the Competitive Upgrade Program:
1. You need to currently be using a commercial competitor to wolfSSL.
2. You will receive up to two weeks of on-site consulting to switch out your old SSL library with wolfSSL. Travel expenses are not included.
3. Normally, two weeks is the right amount of time for us to make the replacement in your code and do initial testing. Additional consulting on a replacement is available as needed.
4. You will receive the standard wolfSSL royalty free license to ship with your product.
5. The price is $10,000.
The purpose of this program is to enable users who are currently spending too much on their embedded SSL implementation to move to wolfSSL with ease. If you are interested in learning more, or interested in how wolfSSL compares to what you are currently using, then please contact us at email@example.com.
The wolfSSL embedded SSL/TLS library supports lwIP, the light weight internet protocol implementation, out of the box. The user merely needs to define
WOLFSSL_LWIP or uncomment the line
/* #define WOLFSSL_LWIP */ in os_settings.h to use wolfSSL with lwIP.
The focus of lwIP is to reduce RAM usage while still providing a full TCP stack. That focus makes lwIP great for use in embedded systems, the same area where wolfSSL is an ideal match for SSL/TLS needs. An active community exists with contributor ports for many systems. Give it a try and let us know if you have any suggestions or questions.
For the latest news and releases of lwIP, you can visit the project homepage, here: http://savannah.nongnu.org/projects/lwip/
For more information, please contact firstname.lastname@example.org.
The CyaSSL embedded SSL library has had support for TLS 1.2 since version 1.1.0 in September of 2009 (over a year and a half ago). We realize that many people don’t know the difference between TLS 1.1 and TLS 1.2, and we wanted to give some quick highlights on the differences between these two protocol versions.
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 in version 1.2 of the TLS protocol. TLS 1.2 support is slowly making it’s way into existing projects. CyaSSL fully supports SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2.
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.
To read more about TLS 1.2, you can find the specification (RFC 5246), here: http://tools.ietf.org/html/rfc5246.
B. 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.
If you would like to read more about SSL or TLS, here are several resources that might be helpful:
TLS – Wikipedia (http://en.wikipedia.org/wiki/Transport_Layer_Security)
TLS 1.0 (RFC 0000): http://tools.ietf.org/html/rfc2246
TLS 1.1 (RFC 0000): http://tools.ietf.org/html/rfc4346
TLS 1.2 (RFC 0000): http://tools.ietf.org/html/rfc5246
As always, if you have any questions or would like more information about the CyaSSL embedded SSL library or the yaSSL Embedded Web Server, please contact email@example.com.
If you`ve been keeping an eye on our blog lately, you`ve probably noticed our series of blog posts about new features and changes we have made in wolfSSL 2.0. If you`re as excited as we are about our next release, we hope you enjoy the following video link:
Release Candidate 1 for wolfSSL 2.0 is available for download from our “Download” page (link). We invite you to download it and take it for a spin. Let us know about any bugs or problems you run into, and if you have any suggestions to make our 2.0 release more robust we`d love to hear them. Please send any comments or questions to firstname.lastname@example.org.
Here`s the third part in a four part series giving a more detailed report on some of the new features present in the recent wolfSSL release.
• Runtime hooks for logging. The wolfSSL embedded SSL library has had the ability to do logging when debug is enabled for some time. Now, logging callback functions can be registered at runtime to provide some more flexibility with how logging is done. The logging callback can be registered with:
int wolfSSL_SetLoggingCb(wolfSSL_Logging_cb log_function);
typedef void (*wolfSSL_Logging_cb)(const int logLevel,
const char *const logMessage);
The log levels can be found in logging.h and the implementation is in logging.c. By default, wolfSSL logs to stderr with fprintf.
• More informative error codes. With the new logging facility an effort was made to change generic errors (-1) to more informative ones. This should aid in the debugging of SSL problems in general and particularly during the SSL handshake.
• More informative logging messages. As with the above feature, an effort was made to have more descriptive logging messages both in error cases and for informational output. These should aid debugging and tracking as well.
• EDH on server side. A wolfSSL server can now do Ephemeral Diffie-Hellman. No build changes are needed to add this feature. Though an application will have to register the ephemeral group parameters on the server side to enable the EDH cipher suites. A new API can be used to do this:
int wolfSSL_SetTmpDH(SSL* ssl, unsigned char* p,int pSz,unsigned char* g,int gSz);
The example server and echoserver use this function from SetDH().
• More robust server downgrade. Both wolfSSL clients and servers now have robust version downgrade capability. If a specific version method is used on either side then only that version will be negotiated or an error will be returned. A client that uses TLSv1 and tries to connect to a SSLv3 only server will fail, likewise connecting to a TLSv1.1 will fail as well. On the other hand, a client that uses SSLv23 (use the highest version supported and downgrade to SSLv3 if needed) will connect to a server running SSLv3 – TLSv1.2. The only version it can`t connect to is SSLv2 which has been insecure for years. Similarly, a server using SSLv23 can handle clients from SSLv3 – TLSv1.2. A wolfSSL server can`t accept a connection from SSLv2 because no security is provided.
We wanted to let our followers know that we`re in the process of porting wolfSSL to FreeRTOS/OpenRTOS. FreeRTOS is a real-time operating system for embedded devices which is designed to be small and simple. Currently, it officially supports 27 architectures and is downloaded over 77 thousand times every year.
Like wolfSSL, FreeRTOS is portable, open source and royalty free. OpenRTOS has an identical code base to FreeRTOS except it offers a commercial license for those projects which would rather not abide by the terms of the GPL.
For a full list of features in FreeRTOS/OpenRTOS, and to learn more about the project in general, visit the FreeRTOS website at http://www.freertos.org/.
If you would like to use wolfSSL with FreeRTOS, or have any questions about our port, please let us know at email@example.com.
- August 2020 (3)
- July 2020 (13)
- June 2020 (18)
- May 2020 (17)
- April 2020 (17)
- March 2020 (7)
- February 2020 (24)
- January 2020 (18)
- December 2019 (9)
- 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)