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. wolfSSL also has a support-specific blog page dedicated to answering some of the more commonly received support questions.

Assembly-Based Performance Optimizations for ARM in wolfSSL

Earlier this week we stated our commitment to ARM by explaining our assembly code optimizations on a number of our math intensive cryptography operations. To give you more information, these optimizations are for Public Key operations with the CTaoCrypt fastmath option. This translates to a speed increase when using RSA, Diffie-Hellman, or DSA.

If you dive into our code, these optimizations can be found in the asm.c source file.

Today, Team yaSSL continues to exhibit at the ARM Technology Conference in Santa Clara, CA. If you are in the area, feel free to stop by our booth to visit or contact us at info@yassl.com with any questions.

The ARM Powered Corvette

The yaSSL booth at ARM TechCon is perfectly situated to check out the QNX based/ARM based Corvette on the show floor.  It’s a silver beauty!  See the pictures below.
 
Reminder:  if you’re building a QNX based car computer and need to secure it with small embedded SSL solution, then contact us.  One of the earliest wolfSSL users did just that, so we have some experience in the domain.

yaSSL lays plans to secure mbed based racing robots

Hi!  As you may know from reading our posts here, Team yaSSL is exhibiting at ARM TechCon this week.  What you may not know is that we’ve been working with ARM’s mbed.org team to facilitate a port of wolfSSL to mbed.  Why?  Because hobbyists need security too!  And it is fun. 
 
Here at ARM TechCon, mbed has paired with Pololu to create an mbed-based robot.  Additionally, these two companies have created a contest for developers to race the robots based on the program they write.  We’re going to help ensure a robot does not lose because its communication is subject to an MITM attack!

How to use the CTaoCrypt crypto library in standalone mode

Hi!  About 20% of our users are using CTaoCrypt to provide standalone cryptographic functionality, and about 80% of our users have not thought about using it that way.  The purpose of this blog post is to inform users on how to use CTaoCrypt as a standalone library:
 
1. CTaoCrypt is available as a function set within wolfSSL, licensed under GPL or commercially.  If you are interested in using it outside of wolfSSL, then let us know.  Basically this means that 100% of the CTaoCrypt functions are available through the wolfSSL API set. 
2. Support for various development environments is included in the download, including GCC, Visual Studio, and Xcode.
3. The build process is described in the README.  A program to test your build is included.
4. If you are a benchmark junkie, and since we know you probably are, we include a simple benchmark application to get you started.
5. CTaoCrypt has a lot of useful features, including: 

– AES-NI support for super fast AES on the newer intel chips. 
– One way hash functions: SHA-1, MD2, MD4, MD5, RIPEMD-160
– Message authentication codes: HMAC
– Block Ciphers: DES, Triple-DES, AES
– Stream Ciphers: ARC4, Rabbit and HC-128
– Public Key Crypto: RSA, DSA, Diffie-Hellman
– Password based key derivation: PBKDF2 from PKCS #5
– Pseudo Random Number Generators
– Large Integer Support
– Base 16/64 encoding/decoding
– DER encoding/decoding
– X.509 processing
– x86, x86_64, SSE2, ARM, PPC32, and PPC64 and AVR32
– Support for FastMath

6. If you need porting, support, or just regular help with CTaoCrypt, then get in contact with us at info@yassl.com.

SHODAN:  Sentient Hyper-Optimized Data Access Network automates port scanning, simplifies exploiting embedded devices

“The Register” reported on using SHODAN to pinpoint embedded devices that are not properly secured yesterday.  See http://www.theregister.co.uk/2010/11/02/scada_search_engine_warning/ for details.  In summary, SHODAN can be used to quickly identify internet connected devices with known exploits.  For us, it points to yet another reason why mobile and embedded systems developers should harden their devices with the wolfSSL embedded SSL library and the yaSSL Embedded Web Server.

Exploiting Devices Lacking SSL Protection at Toorcon

A review of the event from CNET is available here:  https://www.cnet.com/news/researchers-hack-toys-attack-iphones-at-toorcon/.

Of particular interest is Firesheep: http://codebutler.com/firesheep, a firefox browser extension for simplifying SideJacking of open wireless networks.  It is open source, courtesy of Eric Butler and Ian Gallagher.  Their stated goal for developing the tool is creating more awareness of the problem.  We think they’ll achieve their goal!

As a vendor of embedded SSL, you can probably imagine what we think about this, but repetition is the mother of learning, so we’ll repeat:  If you’re building software for embedded devices, you need to enable SSL/TLS.  The most efficient tool for doing that on an embedded environment is wolfSSL.

Need help enabling ssl your device?  Contact us at info@yassl.com

OCSP, RFC 2560 for Embedded SSL

Hi!  Do you need OCSP (Online Certificate Status Protocol) in wolfSSL?  Let us know.  We’re currently considering it for a feature addition to our next release.  Sometimes OCSP may be necessary to obtain timely information about the revocation status of a certificate.  OCSP solves that problem.  Additional status information is also available under the protocol.  More information on the protocol is available here:  http://www.ietf.org/rfc/rfc2560.txt.  This is not a big feature for us to add, but we’re weighing it against other development priorities.  So let us know what you think!  Send in your vote  for or against OCSP being a high priority for wolfSSL to info@yassl.com.

yaSSL Embedded Web Server – CGI Support

The yaSSL Open Source Embedded Web Server has support for CGI (Common Gateway Interface). Using CGI, a web server can communicate with other types of programs running on the server. Because the yaSSL Embedded Web Server by itself is only able to deal with HTML file, it can “pass off” scripts written in other languages to their specific interpreter, thus allowing the functionality of many CGI languages to be used. Some of the possible languages include: PHP, Perl, ASP, ASP.NET, Python, Ruby on Rails, and C.

To configure the yaSSL Embedded Web Server to process CGI scripts in a given language, the interpreter for that language must be installed on the server. As an example, we’ll walk through how you would enable PHP to be used with the yaSSL Embedded Web Server.

The first thing you would need to do would be to download PHP if it is not currently installed on your server. The PHP source can be downloaded from the following location: http://www.php.net/downloads.php. After it has been downloaded, it should be built and installed. From the php source directory, run the following commands:

./configure
make
sudo make install

On OS X, this will place the “php-cgi” program in the “/usr/local/bin” directory. Now that we have the PHP CGI interpreter, we need to let the yaSSL Web Server know where it is located. This can be done in two ways (as most options can) and be set at runtime using the -cgi_interp option, or by adding a similar line to the configuration file. We can also set the -cgi_ext option, which defines which extensions are treated as CGI scripts. Setting these option at runtime, you would start the yaSSL Embedded Web Server as follows:

./yasslEWS -cgi_ext cgi,php -cgi_interp /usr/local/bin/php-cgi

After starting the web server, you can test if PHP is working by browsing to any PHP file which is located under your web server root directory.

To download the yaSSL Embedded Web Server, or to learn more, check out http://www.yassl.com. If you have any questions, contact us at info@yassl.com.

yaSSL Embedded Web Server – Alias Support

The yaSSL Open Source Embedded Web Server supports directory aliases. Similar to Apache’s mod_alias, using aliases allows a mapping to be created between URLs and file system paths. This mapping allows content which is not under the web server Document Root to be served as part of the web document tree. In other words, URLs beginning with the url-path will be mapped to local files beginning with the directory-path.

In the yaSSL Embedded Web Server, this can be done two ways:

1) Aliases can be set at runtime by using the -aliases option
2) Aliases can be set in the config file

In the following examples, suppose we wanted to map our local video directory (/home/user/Videos) to the URL “/videos”, and we wanted to map our pictures directory (/home/user/Pictures) to the URL “/pictures”.

Using the first option (setting the aliases at runtime), would look similar to the following.

./yasslEWS -aliases /videos=/home/user/Videos,/pictures=/home/user/Pictures

Using the second option (setting the aliases through the config file), we would need to add a line to our config file, as follows:

aliases /videos=/home/user/Videos,/pictures=/home/user/Pictures

To test if the newly set-up aliases are working correctly, point your web browser to one of the two URLs, where you should see a directory listing of the local files.

http:///pictures
http:///videos

If this doesn’t work, double check that your paths are correct in your alias definitions and that everything is spelled correctly. Aliases should be able to be created for any drive physically attached to your computer.

To download the yaSSL Embedded Web Server, or to learn more, check out http://www.yassl.com. If you have any questions, contact us at info@yassl.com.

yaSSL Embedded Web Server – ACL Support

The yaSSL Open Source Embedded Web Server supports Access Control Lists. An Access Control List (ACL) allows restrictions to be put on the list of IP addresses which have access to the web server. In the case of the yaSSL Embedded Web Server, the ACL is a comma separated list of IP subnets, where each subnet is prepended by either a ‘-’ or a ‘+’ sign. A plus sign means allow, where a minus sign means deny. If a subnet mask is omitted, such as “-1.2.3.4”, this means to deny only that single IP address.

Subnet masks may vary from 0 to 32, inclusive. The default setting is to allow all, and on each request the full list is traversed – where the last match wins.

The ACL can be specified either at runtime, using the -acl option, or by using “acl” in the config file. For example, to allow only the 192.168.0.0/16 subnet to connect, you would run the following command:

./yasslEWS -acl -0.0.0.0/0,+192.168.0.0/16

The ACL can also be set in the web server config file. Using the example above, the config file line would be:

# acl -0.0.0.0/0,+192.168.0.0/16

To learn more about subnet masks, see the Wikipedia page on Subnetwork (http://en.wikipedia.org/wiki/Subnetwork), or here (http://wiki.xtronics.com/index.php/IP_Subnet_Masks).

To download the yaSSL Embedded Web Server, or to learn more, check out http://www.yassl.com. If you have any questions, contact us at info@yassl.com.

Posts navigation

1 2 3 180 181 182 183 184 185 186 189 190 191

Weekly updates

Archives