wolfSSL Support for the Espressif ESP-IDF v5.2 Beta

Recently Espressif announced their ESP-IDF v5.2 Beta 1 on GitHub. The same day we found out about this exciting new version, we confirmed that all the wolfSSL Espressif ESP32 Examples are working in that environment. So far the “beta” looks to be well polished from our perspective. Last week, we learned about the ESP-IDF v5.2 Beta 2 on GitHub. The final release should be quite nice.

We have both core performance, benchmark, and client-server examples as well as additional examples for the ESP32.

Incorporating wolfSSL in your Espressif project has never been easier. As announced in the summer of 2023 – wolfSSL is now available in the Espressif ESP Registry of managed components: this one line adds wolfSSL to your project:

# Add wolfSSL component to existing ESP-IDF project
idf.py add-dependency "wolfssl/wolfssl"

Get Started with wolfSSL

Additional information on getting Started with wolfSSL on the Espressif environment is available on the wolfSSL GitHub repository as well as this YouTube recording:

Find out more

If you have any feedback, questions, or require support, please don’t hesitate to reach out to us via facts@wolfSSL.com or call us at +1 425 245 8247, or open an issue on GitHub.

Download wolfSSL Now

wolfSSH – Now Available as an Espressif Managed Component Includes SSH Echo Server Example

Not long ago, we announced preview support for new Espressif Managed Components. This is in addition to the core wolfssl managed component. Today you can add SSH capabilities to your toolbox by visiting this link:

https://components.espressif.com/components/wolfssl/wolfssh

If the ESP Registry page does not fully load with all the text, try holding down the “ctrl” key when pressing the refresh button in your browser. The CDN seems to occasionally cache incomplete web content.

Getting started with wolfSSL and wolfSSH has never been easier! You can add wolfSSH to your project with this command:

idf.py add-dependency “wolfssl/wolfssh”

We’ve also included a complete example project to connect to the AWS IoT MQTT. Just click the little “copy” icon and paste into a command prompt after the ESP-IDF has been installed:

Try it

Here’s an example of how the example can be created, built, and flashed onto your ESP32:

# Setup the ESP-IDF Environment (your actual path may vary)
. ~/esp/esp-idf/export.sh

# Download and create the example
idf.py create-project-from-example “wolfssl/wolfssh:wolfssh_echoserver”
cd wolfssl_echoserver

# Set your SSID and wifi Password in Example Connection Configuration
idf.py menuconfig

# Flash the code to your ESP32

idf.py -p /dev/ttyS9 -b 115200 flash monitor

The full wolfSSL repository for wolfSSH contains even more examples for not only this Echo Server Example, but many other target platforms as well.

Get Started with wolfSSL

Additional information on getting Started with wolfSSL on the Espressif environment is available on the wolfSSL GitHub repository as well as this YouTube recording:

Find out more

If you have any feedback, questions, or require support, please don’t hesitate to reach out to us via facts@wolfSSL.com, call us at +1 425 245 8247, or open an issue on GitHub.

Download wolfSSL Now

Live Webinar: Getting Started with wolfSSH in 2024

Join us for a webinar on ‘Getting Started with wolfSSH‘ scheduled for January 18th at 10 am PT. The latest release, wolfSSH v1.4.15, has just been unveiled as part of our Christmas releases! Packed with numerous features and improvements, this version promises an enriching experience.

wolfSSL Software Developer, Jacob Barthelmeh, will be your guide, starting from foundational knowledge and leading you to explore advanced features essential for initiating your journey with wolfSSH!

Save the date: January 18th | 10am PT

Sneak Peek of the webinar:

  • SSH Overview
  • Specifications supported by wolfSSH
  • wolfSSH Architecture
  • Configuration and Build Proces
  • wolfSSH Examples and Applications
    … and much more

Given that 2024 has just begun, this is an ideal moment to be part of our ‘Getting Started’ series! Don’t miss this chance to leverage the expertise of wolfSSL and harness wolfSSH’s potential for your projects! Bring all your wolfSSH-related questions; Jacob is ready to address them.

Register now to secure your spot while seats are available.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfMQTT – Now Available as an Espressif Managed Component Includes AWS IoT MQTT Example

Not long ago, we announced preview support for new Espressif Managed Components in addition to the core wolfssl managed component. Today you can add MQTT capabilities to your toolbox by visiting this link:

https://components.espressif.com/components/wolfssl/wolfmqtt

If the ESP Registry page does not fully load with all the text, try holding down the “ctrl” key when pressing the refresh button in your browser. The CDN seems to occasionally cache incomplete web content.

Getting started with wolfSSL and wolfMQTT has never been easier! You can add wolfMQTT to your project with this command:

idf.py add-dependency “wolfssl/wolfmqtt”

We’ve also included a complete example project to connect to the AWS IoT MQTT. Just click the little “copy” icon and paste into a command prompt after the ESP-IDF has been installed:

Try it

Here’s an example of how the example can be created, built, and flashed onto your ESP32:

# Setup the ESP-IDF Environment (your actual path may vary)
. ~/esp/esp-idf/export.sh

# Download and create the example
idf.py create-project-from-example “wolfssl/wolfmqtt:AWS_IoT_MQTT”
cd AWS_IoT_MQTT

# Set your SSID and wifi Password in Example Connection Configuration
idf.py menuconfig

# Flash the code to your ESP32
idf.py -p /dev/ttyS9 -b 115200 flash monitor

Tada! You have your very own sample MQTT AWS IoT device! Upon a successful connection, output similar to this should be displayed on the serial port being monitored:

I (17096) wolfmqtt main: Initial Stack Used (before wolfSSL Server): 2244 bytes
I (17104) wolfmqtt main: Starting awsiot_main...

AwsIoT Client: QoS 1, Use TLS 1
MQTT Net Init: Success (0)
MQTT Init: Success (0)
NetConnect: Host a2dujmi05ideo2-ats.iot.us-west-2.amazonaws.com, Port 8883, Timeout 5000 ms, Use TLS 1
MQTT TLS Setup (1)
MQTT TLS Verify Callback: PreVerify 0, Error -188 (ASN no signer error to confirm failure)
  Subject's domain name is Starfield Services Root Certificate Authority - G2
  Allowing cert anyways
MQTT Socket Connect: Success (0)
MQTT Connect: Proto (v3.1.1), Success (0)
MQTT Connect Ack: Return Code 0, Session Present 0
MQTT Subscribe: Success (0)
  Topic $aws/things/demoDevice/shadow/update, Qos 1, Return Code 1
MQTT Publish: Topic $aws/things/demoDevice/shadow/update, ID 2, Success (0)
MQTT Waiting for message...
MQTT Message: Topic $aws/things/demoDevice/shadow/update, Qos 1, Len 92
Payload (0 - 92) printing 80 bytes:
{"state":{"reported":{"hardware":{"type":"wolf_aws_iot_demo","firmware_version":
MQTT Message: Done

The full wolfSSL repository for wolfMQTT contains even more examples for not only this Espressif AWS example, but many other target platforms as well.

Get Started with wolfSSL

Additional information on getting Started with wolfSSL on the Espressif environment is available on the wolfSSL GitHub repository as well as this YouTube recording:

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Everything cURL: Your Comprehensive Guide

Get ready to delve into the latest edition of Everything cURL. Daniel Stenberg, the driving force behind cURL, has meticulously crafted the most recent release.

In this comprehensive update of Everything cURL, he’ll take you on an exciting journey through the vast landscape of cURL. Discover not just the technical knowledge but also delve into the origin stories that make this tool a favorite among developers globally.

Everything cURL equips you with a collection of tools, mastering cURL command lines, options, and functionalities at a master level. Whether you seek guidance on crafting HTTP requests or wish to master cURL scripting for automation, this edition covers it all.

It’s your sign to step into the world of cURL. Explore the pages of Everything cURL and uncover the key elements necessary to elevate your development journey with this recent update.

Are you ready to embrace the future of cURL?

Dive into Everything cURL today to kickstart your journey into the world of advanced cURL commands, API usage, and more.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Protecting wolfSSH from Passive SSH Key Compromise

About the Compromise

Recently, a team led by Keegan Ryan from UCSD discovered that several implementations of the SSH protocol have been potentially leaking information about their keys and they came up with a way of exploiting it.

Every now and then, an RSA signature is made with a combination of padding and data that doesn’t verify correctly. If one saves billions of SSH signatures they can analyze the broken signatures and work out some keys.

The team released a paper [1] describing the issue and how it can be analyzed to obtain keys.

The wolfSSH Vulnerability

While wolfSSL verifies an RSA signature after producing it, and erroring out if it doesn’t verify, wolfSSH does not do this process. The compromise has not been proven against wolfSSH, the assumption is that it is possible. wolfSSH did not verify the RSA signatures after generation.

The Fix

As of wolfSSH v1.4.15, just released, we have added the verify step for RSA signatures. Luckily the time to verify an RSA signature is short compared to signing so there shouldn’t be a noticeable slowdown during the key exchange process.

References

  1. Keegan Ryan, Kaiwen He, George Arnold Sullivan, and Nadia Heninger. 2023. Passive SSH Key Compromise via Lattices. Cryptology ePrint Archive, Report 2023/1711. https://eprint.iacr.org/2023/1711.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfSSL Using an fTPM with Xilinx FPGA Microblaze

Have you ever needed a TPM but only had an FPGA available, or needed a TPM for a project and had additional requirements that are not supported by current hardware available? wolfSSL is working on the use of a fTPM (Firmware Trusted Platform Module) running on a Xilinx FPGA Microblaze that is also capable of being used with measured boot. This is unique, in that it can benefit from the additional redundancy that naturally comes with running code on an FPGA while leveraging an existing piece of the hardware on many Xilinx boards rather than requiring additional hardware be added. Use of the fTPM for measured boot will improve sanity checks on the integrity of the boot up process by doing TPM 2.0 PCR extend operations on the initial ROM, FSBL, and partitions loaded.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Espressif RISC-V Hardware Accelerated Cryptographic Functions Up to 1000% Faster than Software

We at wolfSSL continue to embrace the IoT market and congratulate all of the Espressif staff and partners on reaching the 1 Billion Device milestone in 2023. All of those devices need serious, commercial grade security with up to 7×24 support. We are here to help you do that! Of course, wolfSSL software cryptography works on any embedded device, but we’ve also added additional hardware acceleration support to Espressif SoC devices.

Recently our wolfSSL library has been upgraded to support the cryptographic hardware acceleration capabilities on Espressif ESP32 RISC-V SoC boards, specifically the ESP32-C2, ESP32-C3 and the ESP32-C6. The feature set is parity with our ESP32 and ESP32-S2/ESP32-S3 hardware acceleration capabilities which includes SHA (hash), RSA (big number math), and AES encryption. Additional new acceleration hardware capabilities specific to the newer Espressif chipsets are actively in development.

Although we are very proud of our software implementation, no programmatic algorithm can beat the brute strength of hardware acceleration. See below for some of the benchmark performance characteristics. The difference can be up to 10 times faster than equivalent software algorithms.

For instance: The ESP32-C6 has SHA acceleration implemented in hardware for SHA, SHA-224 and SHA-256, all of which are commonly used in TLS hashes. Here’s a comparison of the differences in performance for the ESP32C6:

Taller bars represent more data hashed per second: KiB/s

Note the Espressif GitHub Issue #10423 for the latest ESP32-C6 support status. Silicon version 0.0 was used for testing and benchmarks noted above. Actual production values may differ.

See also our recent blogs:

Additional information on getting Started with wolfSSL on the Espressif environment is available on the wolfSSL GitHub repository as well as a webinar recording, Getting Started with wolfSSL on the Espressif ESP32.

Try it yourself

If you’d like to see the benchmarks on your own device, ensure you have the ESP-IDF installed and follow these steps:

cd [your workspace directory]

# Clone wolfSSL into a local directory
git clone https://github.com/wolfSSL/wolfssl.git
cd wolfssl/IDE/Espressif/ESP-IDF/examples/wolfssl_benchmark

# Set your directory for ESP-IDF, shown here for VisualDGB and WSL
WRK_IDF_PATH=/mnt/c/SysGCC/esp32/esp-idf/v5.1

# Run your ESP-IDF export.sh
. ${WRK_IDF_PATH}/export.sh
# or
. $HOME/esp/esp-idf/export.sh

# Set project target SoC
idf.py set-target esp32c3

# optionally erase your device (substitute /dev/ttyS36 with your port)
idf.py erase-flash -p /dev/ttyS36 -b 115200

# Build and flash the app onto your SoC (substitute /dev/ttyS36)
idf.py build flash -p /dev/ttyS36 -b 115200 monitor -b 115200

Benchmark metrics for the ESP32-C6, Hardware Encryption Enabled:

Chip is ESP32-C6 (revision v0.0), Crystal is 40MHz, cpu freq: 160000000 Hz (160MHz)

------------------------------------------------------------------------------
wolfSSL version 5.6.4
------------------------------------------------------------------------------
wolfCrypt Benchmark (block bytes 1024, min 1.0 sec each)
RNG                       1375 KiB took 1.005 seconds
AES-128-CBC-enc           4450 KiB took 1.004 seconds
AES-128-CBC-dec           4325 KiB took 1.004 seconds
AES-192-CBC-enc           1450 KiB took 1.014 seconds
AES-192-CBC-dec           1425 KiB took 1.010 seconds
AES-256-CBC-enc           4425 KiB took 1.001 seconds
AES-256-CBC-dec           4300 KiB took 1.001 seconds
AES-128-GCM-enc            450 KiB took 1.044 seconds
AES-128-GCM-dec            450 KiB took 1.044 seconds
AES-192-GCM-enc            425 KiB took 1.002 seconds
AES-192-GCM-dec            425 KiB took 1.002 seconds
AES-256-GCM-enc            425 KiB took 1.004 seconds
AES-256-GCM-dec            425 KiB took 1.005 seconds
GMAC Default               602 KiB took 1.000 seconds
3DES                       400 KiB took 1.051 seconds
MD5                      10775 KiB took 1.000 seconds
SHA                      12675 KiB took 1.000 seconds
SHA-224                  12625 KiB took 1.001 seconds
SHA-256                  12625 KiB took 1.001 seconds
SHA-384                   1275 KiB took 1.003 seconds
SHA-512                   1275 KiB took 1.003 seconds
SHA-512/224               1275 KiB took 1.003 seconds
SHA-512/256               1275 KiB took 1.003 seconds
SHA3-224                   925 KiB took 1.005 seconds
SHA3-256                   875 KiB took 1.008 seconds
SHA3-384                   675 KiB took 1.010 seconds
SHA3-512                   475 KiB took 1.019 seconds
SHAKE128                  1075 KiB took 1.009 seconds
SHAKE256                   875 KiB took 1.008 seconds
RIPEMD                    4325 KiB took 1.001 seconds
HMAC-MD5                 10650 KiB took 1.001 seconds
HMAC-SHA                 12475 KiB took 1.001 seconds
HMAC-SHA224              12425 KiB took 1.001 seconds
HMAC-SHA256              12425 KiB took 1.001 seconds
HMAC-SHA384               1275 KiB took 1.019 seconds
HMAC-SHA512               1275 KiB took 1.019 seconds
PBKDF2                       1 KiB took 1.005 seconds
RSA     1024  key gen         1 ops took 1.262 sec, avg 1262.000 ms
RSA     2048  key gen         1 ops took 1.680 sec, avg 1680.000 ms
RSA     2048   public         6 ops took 1.415 sec, avg 235.833 ms
RSA     2048  private         2 ops took 1.040 sec, avg 520.000 ms
ECC   [      SECP256R1]   256  key gen         4 ops took 1.290 sec, avg 322.500 ms
ECDHE [      SECP256R1]   256    agree         4 ops took 1.280 sec, avg 320.000 ms
ECDSA [      SECP256R1]   256     sign         4 ops took 1.296 sec, avg 324.000 ms
ECDSA [      SECP256R1]   256   verify         2 ops took 1.240 sec, avg 620.000 ms
CURVE  25519  key gen         4 ops took 1.276 sec, avg 319.000 ms
CURVE  25519    agree         4 ops took 1.275 sec, avg 318.750 ms
ED     25519  key gen        88 ops took 1.008 sec, avg 11.455 ms
ED     25519     sign        78 ops took 1.022 sec, avg 13.103 ms
ED     25519   verify        52 ops took 1.009 sec, avg 19.404 ms

Benchmark complete

Benchmark metrics for the ESP32-C6, Hardware Encryption Disabled:

Chip is ESP32-C6 (revision v0.0), Crystal is 40MHz, cpu freq: 160000000 Hz (160MHz)

------------------------------------------------------------------------------
wolfSSL version 5.6.4
------------------------------------------------------------------------------
wolfCrypt Benchmark (block bytes 1024, min 1.0 sec each)
RNG                        600 KiB took 1.023 seconds
AES-128-CBC-enc           1725 KiB took 1.004 seconds
AES-128-CBC-dec           1700 KiB took 1.010 seconds
AES-192-CBC-enc           1500 KiB took 1.014 seconds
AES-192-CBC-dec           1475 KiB took 1.013 seconds
AES-256-CBC-enc           1325 KiB took 1.017 seconds
AES-256-CBC-dec           1300 KiB took 1.012 seconds
AES-128-GCM-enc            475 KiB took 1.041 seconds
AES-128-GCM-dec            475 KiB took 1.042 seconds
AES-192-GCM-enc            450 KiB took 1.030 seconds
AES-192-GCM-dec            450 KiB took 1.030 seconds
AES-256-GCM-enc            425 KiB took 1.012 seconds
AES-256-GCM-dec            425 KiB took 1.012 seconds
GMAC Default               621 KiB took 1.000 seconds
3DES                       400 KiB took 1.051 seconds
MD5                      10750 KiB took 1.000 seconds
SHA                       5525 KiB took 1.002 seconds
SHA-224                   1450 KiB took 1.002 seconds
SHA-256                   1450 KiB took 1.001 seconds
SHA-384                   1275 KiB took 1.004 seconds
SHA-512                   1275 KiB took 1.003 seconds
SHA-512/224               1275 KiB took 1.003 seconds
SHA-512/256               1275 KiB took 1.003 seconds
SHA3-224                   925 KiB took 1.006 seconds
SHA3-256                   875 KiB took 1.008 seconds
SHA3-384                   675 KiB took 1.011 seconds
SHA3-512                   475 KiB took 1.019 seconds
SHAKE128                  1075 KiB took 1.009 seconds
SHAKE256                   875 KiB took 1.008 seconds
RIPEMD                    4325 KiB took 1.000 seconds
HMAC-MD5                 10650 KiB took 1.002 seconds
HMAC-SHA                  5475 KiB took 1.002 seconds
HMAC-SHA224               1450 KiB took 1.010 seconds
HMAC-SHA256               1450 KiB took 1.010 seconds
HMAC-SHA384               1275 KiB took 1.019 seconds
HMAC-SHA512               1275 KiB took 1.018 seconds
PBKDF2                       0 KiB took 1.075 seconds
RSA     1024  key gen         1 ops took 7.733 sec, avg 7733.000 ms
RSA     2048  key gen         1 ops took 28.050 sec, avg 28050.000 ms
RSA     2048   public        58 ops took 1.028 sec, avg 17.724 ms
RSA     2048  private         2 ops took 7.051 sec, avg 3525.500 ms
ECC   [      SECP256R1]   256  key gen         4 ops took 1.231 sec, avg 307.750 ms
ECDHE [      SECP256R1]   256    agree         4 ops took 1.225 sec, avg 306.250 ms
ECDSA [      SECP256R1]   256     sign         4 ops took 1.241 sec, avg 310.250 ms
ECDSA [      SECP256R1]   256   verify         2 ops took 1.178 sec, avg 589.000 ms
CURVE  25519  key gen         4 ops took 1.277 sec, avg 319.250 ms, 3.132 ops/sec
CURVE  25519    agree         4 ops took 1.276 sec, avg 319.000 ms, 3.135 ops/sec
ED     25519  key gen        87 ops took 1.001 sec, avg 11.506 ms, 86.913 ops/sec
ED     25519     sign        78 ops took 1.018 sec, avg 13.051 ms, 76.621 ops/sec
ED     25519   verify        52 ops took 1.023 sec, avg 19.673 ms, 50.831 ops/sec
Benchmark complete

Find out more

If you have any feedback, questions, or require support, please don’t hesitate to reach out to us via facts@wolfSSL.com, call us at +1 425 245 8247, or open an issue on GitHub.

Download wolfSSL Now

Protecting wolfSSL against the Marvin attack

About the Marvin Attack

Recently a new variation of a timing Bleichenbacher RSA-decryption attack, termed the Marvin Attack, was reported by Hubert Kario of the RHEL Crypto team. Its name – a nod to a certain android – is a reference to the unending nature of the ROBOT attack.

The vulnerability allows an attacker to decrypt ciphertexts and forge signatures. However the server’s private key is not exposed. In principle the Marvin Attack could enable a Man-in-the-middle attack, but it is not considered likely due to the difficulties involved.

The RHEL team released a paper on the Marvin Attack, along with a tlsfuzzer test suite to detect Marvin and other timing side-channels. The idea of their test suite is that with new statistical techniques (described in their supplementary paper) they can detect timing side-channels much smaller than previously expected. Hence many implementations previously thought to be resilient against timing side-channels are in fact vulnerable to the Marvin Attack.

The wolfSSL Vulnerability

The RHEL Crypto team reported to us that wolfSSL was vulnerable to the Marvin Atack, when built with the following options:
–enable-all CFLAGS=”-DWOLFSSL_STATIC_RSA”
The define “WOLFSSL_STATIC_RSA” enables static RSA cipher suites, which is not recommended, and has been disabled by default since wolfSSL 3.6.6 (even with –enable-all). Therefore the default configuration, even with –enable-all, is not vulnerable to the Marvin Attack. The vulnerability is specific to static RSA cipher suites, and expected to be padding-independent. Additionally, these static RSA cipher suites were removed in TLS 1.3, and are only present in TLS 1.2 and below.

We coordinated with the RHEL Crypto team, and using their tlsfuzzer were able to reproduce the issue. With further testing, we found the vulnerability was not present when building with –enable-sp or –enable-sp-asm (both of which were designed to be constant time). The vulnerability was specific to the SP Math All handling of RSA.

This was a surprising result, as wolfSSL by default includes RSA blinding. The reason is that, even with blinding, the unblinding operation and conversion from big integer to binary array with SP Math All can leave small timing signals that can be resolved by statistical analysis when applied to very many observations (which is what the tlsfuzzer achieves).

We have created a CVE for this issue, [Medium] CVE-2023-6935.

With that said, let’s go through what we did to harden wolfSSL against the Marvin Attack.

The Fixes

These two pull requests were merged to fix the Marvin Attack vulnerability:

  1. https://github.com/wolfSSL/wolfssl/pull/6896
  2. https://github.com/wolfSSL/wolfssl/pull/6955/

The first fix was to make the conversion from a multi-precision integer to padded binary buffer a constant time operation. This fix went into the 5.6.4 release. Following the release we continued to test the issue, and we found that while the fix mitigated the side-channel, it was not sufficient.

The second fix was more involved. It made the blinding inversion multiplication be in Montgomery form, and made subsequent changes so that the Montgomery reduction would be constant time, and clamping and sub-modulo operations were also constant time. Following this second fix we have not detected the Marvin vulnerability, but will continue to test.

Conclusions

  • The wolfSSL SP Math All implementation of RSA was vulnerable to the Marvin Attack. If static RSA cipher suites were enabled on the server side, this meant an attacker could decrypt a saved TLS connection, or forge a signature, after probing with a very large number of test connections. This has been fixed in the current release by the aforementioned two pull requests.
  • Static RSA cipher suites have been disabled by default since wolfSSL 3.6.6. Therefore when using the default configuration of wolfSSL, TLS connections were not vulnerable to the Marvin Attack (even with –enable-all).
  • We found the –enable-sp and –enable-sp-asm RSA implementations are not vulnerable to the Marvin Attack. These implementations are constant time by design.
  • We recommend disabling static RSA cipher suites, and to upgrade the version of wolfSSL used.

References

  1. https://people.redhat.com/~hkario/marvin/
  2. Everlasting ROBOT: the Marvin Attack. https://eprint.iacr.org/2023/1442
  3. Out of the Box Testing. https://eprint.iacr.org/2023/1441.pdf
  4. tlsfuzzer suite. https://github.com/tlsfuzzer/tlsfuzzer

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

wolfMQTT: support for curl easy socket backend

Do you have a need for using MQTT with an http proxy? Users of libcurl know that they can leverage wolfSSL to provide TLS for their applications, and thus enjoy the advantages of both libcurl for data transport and handling http proxies, and wolfSSL for transport security. In this vein, we’ve created a new network layer interface for wolfMQTT that uses libcurl’s easy interface as an optional backend. When enabled, wolfMQTT will use the libcurl easy API (such as curl_easy_send) for the socket backend, while libcurl in turn will use wolfSSL to negotiate TLS. Currently both TLS and mTLS are supported.

You can find our newly added curl easy socket example in examples/mqttnet.c. To try it out, simply build wolfMQTT with –enable-curl. The only prerequisites for this are that wolfSSL has been built with –enable-curl, and curl built with –enable-wolfssl. Supported options with wolfMQTT’s –enable-curl include multithreading (–enable-mt), nonblocking (–enable-nonblock), and as previously mentioned TLS.

If you’re curious for more details, you can look at our updated readme and pull request.

If you have questions about any of the above, please contact us at facts@wolfSSL.com or call us at +1 425 245 8247.

Download wolfSSL Now

Posts navigation

1 2 3