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.

Embedded SSL in the Holiday Spirit

Team yaSSL is preparing for Halloween here in the United States with a pumpkin carving! Our embedded security products are continually evolving. We encourage you to check our our wolfSSL embedded SSL library here, or our new yaSSL Embedded Web Server, here.

As always if you have any questions, or would like more information about our products, please contact us at info@yassl.com.

Thanks,
Team yaSSL

Great Article on Smart Meters in EE Times

See https://www.embedded.com/design/power-optimization/4209515/Robust-design-principles-for-home-smart-grid-metering for a great discussion on smart grid metering.  There’s already wolfSSL users employing our embedded ssl to secure metering systems!  wolfSSL is useful in smart grid metering for the following areas:
 
1. Delivering secure firmware updates to the metering device.
2. Encrypting data between the metering device and the main data store.
3. Encrypting data on the device.
 
Are you building smart grid devices?  Let us know if we can help you with security concerns by contacting us at info@yassl.com.

Notes from wolfSSL at Embedded Systems Computing show in Boston

Hi!  A few notes from exhibiting at Embedded Systems Computing show in Boston.  

1. It`s always fun to hear about what people are doing with embedded systems.  We heard lots of interesting stories about the devices people are building… and securing.

2. The diversity of embedded systems is still amazing, and growing.  From pico-sensors to POS to UAV`s.

3. Team wolfSSL was lucky enough to make it out to Fenway to watch the Red Sox!  Nice to see that historic stadium and see some professional baseball players.  Check out our pictures on Facebook.

4. Feedback on the new yaSSL Embedded Web Server was fun!  Lots of people with lots of interesting ideas on where and why to put a web server on a device!

5. Kerberos Consortium:  We made time to visit the leadership of the Kerberos Consortium at MIT http://www.kerberos.org/.  More on that in a following blog post!

Differences between SSL and TLS Protocol Versions

Have you heard talk about SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3 but never really knew the differences between the different versions? Secure Socket Layer (SSL) and Transport Security Layer (TLS) are both cryptographic protocols which provide secure communication over networks. These different versions are all in widespread use today in applications such as web browsing, e-mail, instant messaging and VoIP, and each is slightly different from the others.

wolfSSL’s embedded SSL/TLS library supports all of these protocols to best suit your needs and requirements. Below you will find lists comparing each version of the SSL/TLS protocols, detailing major changes and updates from version to version.

SSL 3.0

This protocol was released in 1996, but first began with the creation of SSL 1.0 developed by Netscape. Version 1.0 wasn`t released, and version 2.0 had a number of security flaws, thus leading to the release of SSL 3.0. Some major improvements of SSL 3.0 over SSL 2.0 are:

  • Separation of the transport of data from the message layer
  • Use of a full 128 bits of keying material even when using the Export cipher
  • Ability of the client and server to send chains of certificates, thus allowing organizations to use certificate hierarchy which is more than two certificates deep.
  • Implementing a generalized key exchange protocol, allowing Diffie-Hellman and Fortezza key exchanges as well as non-RSA certificates.
  • Allowing for record compression and decompression
  • Ability to fall back to SSL 2.0 when a 2.0 client is encountered

TLS 1.0

This protocol was first defined in RFC 2246 in January of 1999. This was an upgrade from SSL 3.0 and the differences were not dramatic, but they are significant enough that SSL 3.0 and TLS 1.0 don`t interoperate. Some of the major differences between SSL 3.0 and TLS 1.0 are:

  • Key derivation functions are different
  • MACs are different – SSL 3.0 uses a modification of an early HMAC while TLS 1.0 uses HMAC.
  • The Finished messages are different
  • TLS has more alerts
  • TLS requires DSS/DH support

TLS 1.1

This protocol was defined in RFC 4346 in April of 2006, and is an update to TLS 1.0. The major changes are:

  • The Implicit Initialization Vector (IV) is replaced with an explicit IV to protect against Cipher block chaining (CBC) attacks.
  • Handling of padded errors is changed to use the bad_record_mac alert rather than the decryption_failed alert to protect against CBC attacks.
  • IANA registries are defined for protocol parameters
  • Premature closes no longer cause a session to be non-resumable.

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. 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.

TLS 1.3

This protocol is currently being revised, and is in its 28th draft. The major differences from TLS 1.2 include:

  • The list of supported symmetric algorithms has been pruned of all legacy algorithms. The remaining algorithms all use Authenticated Encryption with Associated Data (AEAD) algorithms.
  • A zero-RTT (0-RTT) mode was added, saving a round-trip at connection setup for some application data at the cost of certain security properties.
  • Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
  • All handshake messages after the ServerHello are now encrypted.
  • Key derivation functions have been re-designed, with the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) being used as a primitive.
  • The handshake state machine has been restructured to be more consistent and remove superfluous messages.
  • ECC is now in the base spec and includes new signature algorithms. Point format negotiation has been removed in favor of single point format for each curve.
  • Compression, custom DHE groups, and DSA have been removed, RSA padding now uses PSS.
  • TLS 1.2 version negotiation verification mechanism was deprecated in favor of a version list in an extension.
  • Session resumption with and without server-side state and the PSK-based ciphersuites of earlier versions of TLS have been replaced by a single new PSK exchange.

 

Resources:

If you would like to read more about SSL or TLS, here are several resources that might be helpful:
TLS Wikipedia article: http://en.wikipedia.org/wiki/Transport_Layer_Security
TLS 1.3 overview: https://www.wolfssl.com/docs/tls13/

As always, if you have any questions or would like to talk to the wolfSSL team about more information, please contact facts@wolfssl.com.

wolfSSL Supports the RIM PlayBook

Did you know that wolfSSL supports running on the RIM PlayBook? The PlayBook runs the QNX operating system, which we have supported for the last five years – ever since our first source release of wolfSSL.

We have posted before about wolfSSL`s build sizes on QNX, which are an impressive 80k (compared to a standard OpenSSL build of 2M). With QNX`s successful track record, we are proud to support the RIM PlayBook.

If you plan on trying out wolfSSL on the PlayBook, let us know! In addition, if you need any help with wolfSSL and QNX, we`d be more than happy to help out! For more information on wolfSSL`s feature list, please see the wolfSSL product page.

View the PlayBook product page: http://na.blackberry.com/
Learn more about QNX from their website: http://www.qnx.com/

If you have any questions or want more information, please contact info@yassl.com.

Meet the yaSSL crew at Embedded Live in London

Hi!  We’ll be exhibiting at Embedded Live in London on October 20th and 21st.  We’ll be talking about how to use wolfSSL to enable your secure firmware update systems, the yaSSL Embedded Web Server, and of course wolfSSL Embedded SSL.  If you are a wolfSSL user or customer in the London area and want to get together with us, just let us know and we’ll try to accommodate you.
 
Also, if you need an exhibits hall pass, then please contact us at info@yassl.com and we’ll mail you one!

EE Times reports on VDC Research survey of Embedded Software

See Jack Ganssle’s discussion on the report here:  https://www.embedded.com/electronics-blogs/break-points/4208881/2010-VDC-survey-of-embedded-software.  A couple items stand out for us, as a company providing open source embedded ssl:
 
1. 46% of embedded developers are using a TCP/IP stack.  What we’d like to know is the subset of those developers using SSL.  If embedded ssl usage maps to general ssl usage studies, it would be about 1-2%.  That means a whole lot of devices in a whole lot of places are subject to man in the middle attacks, and worse.

1. The survey also tells us that about 20% of the developers are using open source in some fashion, but it does not tell us why they chose open source.  In any event, 20% is a good start!  We’d like to pull out our soap box and lecture on why open source produces higher quality software faster than legacy proprietary approaches, but that argument is well documented elsewhere.

wolfSSL SSL Sniffer Support

Do you have a need to analyze SSL traffic? Beginning with the wolfSSL 1.5.0 release, we have provided a build option allowing the wolfSSL embedded SSL library to be built with SSL Sniffer functionality. This means that you can collect SSL traffic packets and with the correct key file, are able to decrypt them as well. This could be useful for several reasons, including:

– Analyzing Network Problems
– Detecting network misuse by internal and external users
– Monitoring network usage and data in motion
– Debugging client/server communications

To enable sniffer support, build wolfSSL with the –enable-sniffer option on *nix or use the vcproj files on Windows. You will need to have pcap installed on *nix or WinPcap on Windows. There are five main sniffer functions which can be found in sniffer.h. They are listed below with a short description of each:

ssl_SetPrivateKey – Sets the private key for a specific server and port.
ssl_DecodePacket – Passes in a TCP/IP packet for decoding.
ssl_Trace – Enables / Disables debug tracing to the traceFile.
ssl_InitSniffer – Initialize the overall sniffer.
ssl_FreeSniffer – Free the overall sniffer.

To look at wolfSSL`s sniffer support and see a complete example, please see the “snifftest” app in the “ssSniffer/sslSnifferTest” folder from the wolfSSL download.

Keep in mind that because the encryption keys are setup in the SSL Handshake, the handshake needs to be decoded by the sniffer in order for future application data to be decoded. For example, if you are using “snifftest” with the wolfSSL example echoserver and echoclient, the snifftest application must be started before the handshake begins between the server and client.

If you have questions or would like more information, please contact info@yassl.com.

wolfSSL Build Sizes for the QNX Embedded RTOS

wolfSSL embedded ssl has been available for QNX since the first source release of the product.  We have compared wolfSSL’s current build size on QNX against OpenSSL and the results surprised us.  A standard wolfSSL build for QNX is 80k.  This compares to a standard OpenSSL build size of 2M.  The wolfSSL embedded implementation is more than 25 times smaller than OpenSSL on QNX! 

You can find more information about QNX from their website: http://www.qnx.com/

If you have any questions or want more information, please contact info@yassl.com.

Posts navigation

1 2 3 95 96 97 98 99 100 101 102 103 104

Weekly updates

Archives

Latest Tweets