wolfSSL Apache Mynewt port

The wolfSSL embedded SSL/TLS library features many different ports, including one for Apache Mynewt. Apache Mynewt is a Real-Time Operating System (RTOS) that is used to build, deploy, and securely manage billions of devices. It is designed for IoT devices that have limited memory and storage and need to run for a long time with minimal power consumption. wolfSSL's port for Mynewt uses Mynewt's raw socket interface "mnsocket" to send and receive data through an SSL/TLS connection.

The wolfSSL port for Apache Mynewt is the ideal solution for security in your embedded IoT device. Apache Mynewt is an RTOS created with resource constrained devices in mind, and wolfSSL is an embedded SSL/TLS library created with speed, strength, portability, and low footprint size in mind. The combination of wolfSSL and Apache Mynewt results in a powerful security solution.

For more information, please contact facts@wolfssl.com.

wolfSSL also provides support for TLS 1.3, the most recent version of the TLS protocol!

Resources
wolfSSL release notes: https://www.wolfssl.com/docs/wolfssl-changelog/
Apache Mynewt homepage: https://mynewt.apache.org

Why They Use curl

authored by Daniel Stenberg - original post: https://gist.github.com/bagder/5970df691b7cdef65e95d3d48ebd8659

You most probably already know why you would use curl and if I'm right, you're also a fan of using the right tool for the job. But do you know why others use curl and why they switch from other solutions to relying on curl for their current and future data transfers? Let me tell you the top reasons I'm told by users.

Logging and exact error handling

What exactly happened in the transfer and why are terribly important questions to some users, and with curl you have the tools to figure that out and also be sure that curl either returns failure or the command worked. This clear and binary distinction is important to users for whom that single file every transfer is important. For example, some of the largest and most well-known banks in the world use curl in their back-ends where each file transfer can mean a transfer of extremely large sums of money.

A few years ago I helped a money transaction service switch to curl to get that exact line in the sand figured out. To know exactly and with certainty if money had been transferred - or not - for a given operation. Vital for their business.

curl does not have the browsers' lenient approach of "anything goes as long as we get something to show" when it comes to the Internet protocols.

Verbose goodness

curl's verbose output options allow users to see exactly what curl sends and receives in a quick and non-complicated way. This is invaluable for developers to figure out what's happening and what's wrong, in either end involved in the data transfer.

curl's verbose options allows developers to see all sent and received data even when encryption is used. And if that is not enough, it's SSLKEYLOGFILE support allows you to take it to the next level when you need to.

Same behavior over time

Users sometimes upgrade their curl installations after several years of not having done so. Bumping a software's version after several years and many releases, any software really, can be a bit of a journey and adventure many times as things have changed, behavior is different and things that previously worked no longer do etc.

With curl however, you can upgrade to a version that is a decade newer, with lots of new fancy features and old crummy bugs fixed, only to see that everything that used to work back in the day still works - the same way. With curl, you can be sure that there's an enormous focus on maintaining old functionality when going forward.

Present on all platforms

The fact that curl is highly portable, our users can have curl and use curl on just about any platform you can think of and use it with the same options and behaviors across them all. Learn curl on one platform, then continue to use it the same way on the next system. Platforms and their individual popularity vary over time and we enjoy to allow users to pick the ones they like - and you can be sure that curl will run on them all.

Performance

When doing the occasional file transfer every once in a while, raw transfer performance doesn't matter much. Most of the time will then just be waiting on network anyway. You can easily get away with your Python and java frameworks' multiple levels of overhead and excessive memory consumption.

Users who scan the Internet or otherwise perform many thousands of transfers per second from a large number of threads and machines realize that they need fewer machines that spend less CPU time if they build their file transfer solutions on top of curl. In curl we have a focus on only doing what's required and it's a lean and trimmed solution with a well-documented API built purely for Internet data transfers.

The features you want

The author of a banking application recently explained for us that one of the top reasons why they switched to using curl for doing their Internet data transfers, is curl's ability to keep the file name from the URL.

curl is a feature-packed tool and library that most likely already support the protocols you need and provide the power features you want. With a healthy amount of "extension points" where you can extend it or hook in your custom extra solution.

Support and documentation

No other tool or library for internet transfers have even close to the same amount of documentation, examples available on the net, existing user base that can help out and friendly users to support you when you run into issues. Ask questions on the mailing lists, post a bug on the bug tracker or even show your non-working code on stackoverflow to further your project.

curl is really the only Internet transfer option available to get something that's old and battle-proven proven by the giants of the industry, that is trustworthy, high-performing and yet for which you can also buy commercial support for, today.

wolfSSL Apache Port Coming Soon!

wolfSSL provides the wolfSSL embedded SSL/TLS library, which is a fast, secure, and highly portable implementation of the SSL/TLS protocols. As part of being highly portable, the wolfSSL library is frequently being ported to various other software modules and devices for users to easily implement wolfSSL's features. One of these more recent ports that wolfSSL has is a port to the Apache HTTP server project coming out soon!

Apache is an effort to develop and maintain an open-source HTTP server for modern operating systems including UNIX and Windows. Its goal is to provide a secure, efficient and extensible server that provides HTTP services in sync with the current HTTP standards. Using wolfSSL with Apache will also allow users to implement some of the other high profile features offered by wolfSSL, such as TLS 1.3 support, FIPS 140-2 validated code, and dual-licensed commercial support. wolfSSL also provides an OpenSSL compatibility layer, which can be easily used to switch from using OpenSSL's security to using wolfSSL's security.

For more information, please contact facts@wolfssl.com.

wolfSSL and the Zombie POODLE and GOLDENDOODLE Attacks

The wolfSSL library is NOT vulnerable to these attacks, thanks to previous fixes we've made and our extensive testing.

These attacks were presented by Craig Young at BlackHat Asia 3/29/2019 (slides).

Both attacks target the MAC and Padding used for TLS v1.2 with AES CBC cipher suites. TLS padding occurs when a record is not 16-byte aligned and is padded with the length value. The MAC uses HMAC with SHA/SHA256 to calculate an authention code. For TLS the order of operation is MAC -> PAD -> ENCRYPT.

The attack requires a man-in-the-middle (MITM) position to employ the attack. It takes valid records and alters either MAC or Padding or cause TLS errors. If the TLS server responds differently to each of these errors then it can leak information about the plain text message.

The author Craig Young wrote a "padcheck" tool, which tests the following error cases:

  1. Invalid MAC with Valid Padding (0-length pad)
  2. Missing MAC with Incomplete/Invalid Padding (255-length pad)
  3. Typical POODLE condition (incorrect bytes followed by correct length)
  4. All padding bytes set to 0x80 (integer overflow attempt)
  5. Valid padding with an invalid MAC and a 0-length record

For wolfSSL we respond consistently with the same alert and close the socket for each ofl these conditions.

The recommendation from the author is to stop using AES CBC cipher suites and start using TLS v1.3, which is supported by wolfSSL. More information about wolfSSL and TLS 1.3 can be found here: https://www.wolfssl.com/docs/tls13/

For more information about wolfSSL, please contact facts@wolfssl.com.

TLS 1.3 Performance Analysis – Server Pre-Generation

TLS 1.3 has some significant changes from TLS 1.2 that are targeted at performance. This is the fourth part of six blogs discussing the performance differences observed between TLS 1.2 and TLS 1.3 in wolfSSL and how to make the most of them in your applications. This blog discusses the server generating a key pair before the handshake starts.

As mentioned in the first blog in this series there is a way to mitigate some of the key exchange cost in TLS 1.3. If the server knows which key exchange algorithm will be used, it can preemptively generate a key pair after accepting a TCP/IP connection by calling wolfSSL_UseKeyShare(). In an architecture where both end-points are controlled by the same entity, a choice of security parameters, like the key exchange algorithm, is made upfront and can be relied on.

When directly connecting to a server, typically, a client only starts creating the ClientHello once a TCP/IP connection has been made. The server accepts the connection and waits for the client to generate a key share and send a ClientHello message. In this time, the server can also generate a key pair.

When using DH for key exchange this provides a significant saving as key generation is expensive. For example when using RSA for server authentication and running both client and server on the same computer, the connection is about 20% faster and with session reuse or PSK for server authentication, the connection is about 30% faster. For connections using ECDH with ECDSA for server authentication, the connection is only about 4% faster and with session reuse or PSK for server authentication, the connection is about 7% faster. EC key generation is very fast in optimised implementations and the impact of hiding its cost is therefore less.

Servers currently reuse the ephemeral key pair across multiple connections. It is common to regenerate the key pair once an hour up to once a day. This mechanism can be used instead of server pre-generation but at the cost of perfect forward security for the server.

If your architecture allows for it, the server should be implemented to generate the key pair after accepting a connection. For DH, it is well worth it. But even for ECDH the small performance improvement will result in more connections per second.

The next blog will discuss the performance issues with handshakes performing client-server authentication.

Part 1 (TLS 1.3 Performance – Resumption)
Part 2 (TLS 1.3 Performance – Full Handshake)
Part 3 (TLS 1.3 Performance – Pre-Shared Key (PSK))

wolfSSL at Satellite 2019

wolfSSL is at Satelilite this year! The Satellite experience includes networking opportunities, SGx, Tech Demos, a Startup Space, and an international resource center curated from the 15k+ attendees from over 100 countries who come together for this global show. Connectivity and aerospace professionals will lead discussions on the future of satellite connectivity and the changing market landscape, hundreds of industry peers will be exhibiting cutting-edge technologies to buyers in enterprise, finance, military and government, telecommunications and transportation sectors. For 2019, Satellite will be located in Washington, DC.

Where Satellite will be :
Venue: Walter E. Washington Convention Center
Booth #: 838
When: May 6-8, 2019
Directions: https://2019.satshow.com/travelling-to-satellite/

Stop by to hear more about the wolfSSL embedded SSL/TLS library, the wolfCrypt encryption engine, to meet the wolfSSL team, or to get some free stickers and swag!

For more information about wolfSSL, its products, or future events, please contact facts@wolfssl.com.

More information about Satellite can be found here: https://2019.satshow.com.

TLS 1.3 Performance Analysis – Pre-Shared Key (PSK)

TLS 1.3 has a different handshake flow when using pre-shared keys and this impacts performance. This is the third part of six blogs discussing the performance differences observed between TLS 1.2 and TLS 1.3 in wolfSSL and how to make the most of them in your applications. This blog discusses how and why PSK handshakes are only similar in speed generally but faster when using DH style key exchange.

For TLS 1.2, handshakes using PSK are defined in a separate document (RFC 4279). In order to fit in with the existing flow, a full handshake is performed. In TLS 1.3, PSK handshakes are the same as resumption handshakes. Therefore there is one less round-trip required for TLS 1.3.

This change in flow has a significant impact on the performance of TLS 1.3. The amount of hashing and encryption/decryption has increased but losing a round-trip means that using PSK without a DH style key exchange is only slightly slower. On higher latency networks, the difference is trivial and the savings great.

In TLS 1.3 using DH or ECDH with PSK results in the following handshake operations.

So, the secret is calculated on the server after the ServerHello is sent. This means that the processing of the ServerHello and secret calculation on the client is happening at the same time relative to the server calculating the secret. The parallel secret generation resulted in, with client and server running on the same computer, TLS 1.3 being about 25% faster than TLS 1.2 when using DH. Using ECDH with P-256, TLS 1.3 is about 15% faster.

It is clear that using pre-shared keys in a secure way, with DH style key exchange, is faster with TLS 1.3 in wolfSSL. The next blog will discuss use cases that result in the removal of a key generation from the list of expensive cryptographic operations in TLS 1.3.

Part 1 (TLS 1.3 Performance – Resumption)
Part 2 (TLS 1.3 Performance – Full Handshake)

For more information regarding wolfSSL performance or usage of PSK, please contact facts@wolfssl.com.

Differences between TLS 1.2 and TLS 1.3 (#TLS13)

wolfSSL's embedded SSL/TLS library has included support for TLS 1.3 since early releases of the TLS 1.3 draft. Since then, wolfSSL has remained up-to-date with the TLS 1.3 specification. In this post, the major upgrades of TLS 1.3 from TLS 1.2 are outlined below:

TLS 1.3

This protocol is defined in RFC 8446. TLS 1.3 contains improved security and speed. The major differences 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.

More information about the TLS 1.3 protocol can be found here: https://www.wolfssl.com/docs/tls13/. Additionally, please contact facts@wolfssl.com for any questions.

OpenSSL Compatibility Layer Expansion

Recently, wolfSSL released version 4.0.0 of the wolfSSL embedded SSL/TLS library. This new version includes many new port/feature additions, maintenance updates, and a couple bug fixes. Among those new feature additions includes multiple new API added to wolfSSL's OpenSSL compatibility layer! The compatibility layer is a series of commonly used and essential API that users can utilize to transition from OpenSSL to wolfSSL. The function names are redefined as their wolfSSL counterparts, which have similar signatures and output to their OpenSSL counterparts.

The list of new compatibility API included with the most recent release include the following:

  • BN_Init
  • EVP_Digest
  • EVP_MD_CTX_block_size
  • EVP_MD_CTX_size
  • EVP_PKEY_assign_EC_KEY
  • EVP_PKEY_assign_RSA

The list of OpenSSL compatibility API that were added in the release prior can be found here: https://www.wolfssl.com/openssl-compatibility-layer-expansion-2/

wolfSSL also provides support for TLS 1.3! More information can be found here: https://www.wolfssl.com/docs/tls13/.

wolfSSL is available for download at the wolfSSL download page here (https://www.wolfssl.com/download/), or through a git-clone of the wolfSSL repository here (https://github.com/wolfssl/wolfssl.git).

For more information about wolfSSL or porting from OpenSSL, please contact facts@wolfssl.com.

wolfSSL at LinuxFest Northwest

wolfSSL is at LinuxFest Northwest (LFNW) this year! Bellingham Linux Users Group and the Information Technology department at BTC co-produce this annual Open Source event in Washington state. Attend presentations and exhibits on free and open source topics as well as Linux distributions and applications, InfoSec and privacy. For 2019, LFNW will be located in Bellingham, WA.

Where LFNW will be :
Venue: Bellingham Technical College
When: April 26-28, 2019
Directions: https://linuxfestnorthwest.org/conferences/2019#venue

Stop by to hear more about the wolfSSL embedded SSL/TLS library, the wolfCrypt encryption engine, to meet the wolfSSL team, or to get some free stickers and swag!

For more information about wolfSSL, its products, or future events, please contact facts@wolfssl.com.

More information about LFNW can be found here: https://linuxfestnorthwest.org/conferences/2019.

Posts navigation

1 2 3 97 98 99 100 101 102 103 188 189 190