As heavy users of the C language and Unix operating environments, we`ll simply note our gratitude for Ritchie`s work. There`s any number of articles on the topic of his passing.
One of the best ones is here:
http://www.wired.com/wiredenterprise/2011/10/dennis-ritchie/
Wikipedia (Dennis Ritchie): http://en.wikipedia.org/wiki/Dennis_Ritchie
The latest release of wolfSSL is now ready for download: http://yassl.com/yaSSL/Download.html .
New features in the embedded SSL release include better autoconf support, allowing easier integration with other projects whether those projects use autoconf or not. More complete make install and uninstall, using the default system directories. make test / make check are now implemented. The wolfSSL headers are now in
Special thanks to Brian Aker for his suggestions and patches that contributed to the overhaul. For more information check out the updated wolfSSL Manual.
Team yaSSL
It has been widely publicized that TLS (any version less than or equal to 1.0), using AES-CBC mode has been recently cracked. We have received a number of questions and there has been a flurry of activity in the SSL world around this topic. Hence, we feel compelled to make a few statements of our own. Here are our thoughts:
1. The current crack is specific to TLS, versions less than or equal to 1.0. We support both TLS 1.1 and TLS 1.2.
2. We have supported TLS 1.2 for over 18 months now, and believe that we have the most robust and well tested implementation.
3. We can also note that we`ve done as much TLS 1.2 interop testing as possible.
To protect yourself from this attack, we recommend using either TLS 1.1 or TLS 1.2 in your project or application. If you must use an older version of the protocol (SSL 3.0, TLS 1.0), we recommend that you use stream ciphers, as they are not vulnerable to the CBC crack. wolfSSL supports several stream ciphers including ARC4, RABBIT, and HC-128. For a full list of wolfSSL features, please see the product page.
References on the above will follow in further posts on our blog. If you have any questions, please contact us at info@yassl.com.
We recently ported the wolfSSL embedded SSL library to FreeRTOS. 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. If you are running your project on FreeRTOS and need SSL/TLS support, give wolfSSL a try and see what you think. The wolfSSL embedded SSL library supports the industry standards up to TLS 1.2 and is optimized for embedded environments.
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 have any questions about using wolfSSL with FreeRTOS, please contact us at info@yassl.com.
Thanks!
yaSSL is strongly committed to fostering both partnerships and community, and as such, we make it a point to go out of our way to support both. We can now report that yaSSL is a General Member of the Intel Embedded Alliance: a community of embedded developers and solution providers. We hope to see new opportunities arise through this membership that will be beneficial to both yaSSL and our users.
You can now find wolfSSL and the yaSSL Embedded Web Server listed in the Intel Embedded Alliance Solutions Directory:
wolfSSL Embedded SSL Library: Directory Link
yaSSL Embedded Web Server: Directory Link
If you are interested in forming a partnership with yaSSL, or have any questions regarding our partnership or community involvement, please contact us info@yassl.com.
Are you developing for Android? If so, we have recently created an Android NDK package for the wolfSSL Embedded SSL library. Using this package as a guide, you should be able to easily integrate the native wolfSSL library into your Android application for either SSL or cryptography use.
wolfSSL supports the current SSL standards up to TLS 1.2 as well as a long list of ciphers (which can be used individually by your application as well), and is dual licensed under both the GPLv2 as well as a standard commercial license. For a full list of features of the wolfSSL embedded SSL library, please see the product page, here: wolfSSL Product Page.
The wolfSSL NDK contains the wolfSSL library as well as a sample application that runs through tests of the CTaoCrypt crypto library. You can find the NDK package at the following GitHub repository: https://github.com/cconlon/cyassl-android-ndk.
Let us know what you think at support@yassl.com. We welcome your feedback and constructive criticism to make our package better.
– Team yaSSL
Some of you may be familiar with the TLS 1.2 signature_algorithm extension, and might be curious if wolfSSL supports it. The signature_algorithm extension is found in section 7.4.1.4.1 RFC5246 (http://tools.ietf.org/html/rfc5246#section-7.4.1.4.1), and is a hello extension of type supported_signature_algorithms. The purpose of this extension is to allow clients to indicate to the server which signature/hash algorithm pairs may be used in digital signatures. If the client supports the default algorithms, the client is not required to send this extension.
wolfSSL supports the default algorithms, and as such, the wolfSSL client does not support this extension. The wolfSSL server will accept this extension if received from a client, but currently doesn’t do anything with the response it receives. This is something that will most likely be added to wolfSSL in the future when more clients and servers start using non-default extension algorithms.
If you have any questions about wolfSSL, or would like more information, please let us know at info@yassl.com.
Thanks,
Team yaSSL
Are you currently using wolfSSL in your open source, community, or hobby project? If so, we’d love to hear about what you’ve done so far and what your plans are for the future. yaSSL is dedicated to helping community-based projects who are using the wolfSSL embedded SSL library or the yaSSL Embedded Web Server. Let us know about your project at info@yassl.com and we’ll put you up on our Community page.
Technical support for community-based open source projects is free and available either through our support forums, or by emailing us directly at support@yassl.com.
To access and download our most recent wolfSSL source code, please visit our project page on GitHub, here. As always, please feel free to contact us with any questions you might have regarding our products.
Thanks!
Team yaSSL
You may have not realized it, but wolfSSL is very popular for game development, and is in use in millions of games.
Here`s why:
1. Experienced: The yaSSL team has been supplying game developers with an efficient, portable SSL Stack for years.
2. Small: Our code size is small. We won`t bog down your game.
3. Portable: We run on all the major gaming consoles/platforms and some of the minor ones.
4. Scalable: Building a MMPORG and require security? We have experience helping with that too. wolfSSL won`t consume all of your server`s memory.
5. Streaming media: wolfSSL was built with securing streaming media in mind.
Let us know if you have questions. If you are a game developer and would like to speak with our references in the gaming industry, just email us at info@yassl.com.
One predominant question we get asked frequently is what are the build size and runtime memory usage of the wolfSSL embedded SSL library. Hopefully this post will help clear things up.
Firstly, wolfSSL was built from the ground up to be optimized for embedded and resource-constrained devices and environments. As such, we have kept a close eye on keeping our SSL library small while still providing the features our users want and need.
Build sizes (compiled binary size) for wolfSSL range between 30-100kB depending on build options and the compiler being used. Typically on an embedded system, build sizes will be around 60kB. This size will include a full-featured TLS 1.2-compliant client and server. For details on build options, please see Chapter 2 of the wolfSSL Manual.
Looking at runtime memory usage, wolfSSL will generally consume somewhere between 5-50kB (average is around 3kB). The runtime RAM usage per connection will vary depending the size of the input/output buffers being used. For example, with standard 16kB buffers, the total runtime memory usage of wolfSSL with a single connection would be 3kB + 16kB + 16kB = 35kB.
If you have any further questions about wolfSSL code sizes, please contact us at info@yassl.com. For a full list of wolfSSL features, please visit the wolfSSL Product Page.
