1 Topic by Scoobi_FreeBSD

(1 replies, posted in wolfSSL)

We're using WolfSSL v4.4.0 with the Atmel port, and the WolfSSL peer is sending a bad_record_mac alert when trying to do TLSv1.3 with a HAProxy 2.0.12 server.  Our WolfSSL product is an embedded one which uses a Microchip (formerly Atmel) cryptographic hardware chip.

We see the alert when the WolfSSL peer downloads ~500KiB over HTTPS.  The alert manifests itself in different ways:

  • When it occurs during connection establishment, we get a "bad certificate" error

  • During data transfer, we get a TCP connection reset as the peer side shuts down its end of the connection

I have not confirmed, but I believe the WolfSSL peer is always the one failing to validate the MAC of a message and responding with an alert sent to the HAProxy peer.

The anomaly occurs pretty frequently when the WolfSSL peer is communicating from $job's network (nearly 50% of transfers fail to complete), but much less frequently when communicating via my home AT&T fiber ISP (<5% of transfers fail).  The failure may occur at any point during the transfer.

Googling suggests several possible culprits:

  • One peer is using an old OpenSSL library with a known bug that causes this issue (disproven; HAProxy was built with OpenSSLv1.1.1)

  • The peer sending the bad message is using OpenSSL incorrectly in a multithreaded application (unlikely; HAProxy was designed as a multithreaded application)

  • TCP packet corruption (unlikely, as TCP checksumming should rarely allow a bad packet to pass a checksum check)

Questions:

  1. Could a sporadic crytpo operation failure cause this behavior?

  2. If the WolfSSL peer is only receiving corrupt messages, would that exonerate our WolfSSL peer from blame?

  3. Any tips on pinpointing the culprit?

Thanks in advance!

Go to forum: wolfSSL

2 Reply by Scoobi_FreeBSD

(2 replies, posted in wolfMQTT)

Awesome, thanks!!!

Okay, to summarize for anyone also looking for this information, it looks like:

for callback function message_cb with prototype

int message_cb(MqttClient *client, MqttMessage *msg, byte msg_new, byte msg_done)

  • msg->buffer points to the start of the i'th chunk of the message received from the broker

  • msg->buffer_pos is the absolute position of the i'th chunk in the total message

  • msg->buffer_len is the length of the i'th chunk of the message received from the broker

  • msg->total_len is the sum of all msg->buffer_len (i.e. the total length of the message)

  • msg_new = nonzero for i = 0

  • msg_done = nonzero for i = n-1, where n = the number of message chunks sent (and the number of calls to the callback)

Go to forum: wolfMQTT

3 Topic by Scoobi_FreeBSD

(2 replies, posted in wolfMQTT)

I apologize if I missed this in the WolfMQTT manual, but I'm not clear how to receive a large MQTT message from the broker (received message is larger than the buffer passed to MqttClient_Init()).  What is the sequence of calls to the callback function for such a message, including the values of callback function parameters msg_new, msg_done, msg->buffer, msg->buffer_len and msg->buffer_pos.

If this info is in the manual, a pointer to where it is would be appreciated.

Thanks!
Anthony Jenkins

Go to forum: wolfMQTT

4 Reply by Scoobi_FreeBSD

(3 replies, posted in wolfSSL)

  • wolfcrypt/src/random.c:
    WOLFSSL_uITRON4 forces the definition of USE_TEST_GENSEED unless a custom random number generator is enabled

  • wolfcrypt/src/wc_port.c:
    Defining WOLFSSL_uITRON4 without defining SINGLE_THREADED calls acre_sem(), which constructs a semaphore at runtime, but our uITRON implementation defines all RTOS resources statically (at compile-time).  I've worked around this by defining WOLFSSL_USER_MUTEX and using an atomic XCHG instruction and RTOS sleep calls, but WOLFSSL_USER_MUTEX is tested after testing WOLFSSL_uITRON4, preventing the user from overriding WolfSSL's implementation.

  • wolfssl/wolfcrypt/settings.h:
    WOLFSSL_uITRON4 declares external functions uITRON4_minit(), uITRON4_malloc(), uITRON4_realloc() and uITRON4_free() which our uITRON implementation does not have.  Are we responsible for implementing these functions?

I suppose we could define SINGLE_THREADED to build a single-threaded library, but we are running in a multi-task environment.

Go to forum: wolfSSL

5 Topic by Scoobi_FreeBSD

(3 replies, posted in wolfSSL)

WolfSSL header file wolfssl/internal.h includes pthread.h if none of the following macros is defined

USE_WINDOWS_API
THREADX
WOLFSSL_DEOS
MICRIUM
FREERTOS
FREERTOS_TCP
WOLFSSL_SAFERTOS
EBSNET
FREESCALE_MQX
FREESCALE_KSDK_MQX
FREESCALE_FREE_RTOS
WOLFSSL_uITRON4
WOLFSSL_uTKERNEL2
WOLFSSL_CMSIS_RTOS
WOLFSSL_MDK_ARM
MBED
WOLFSSL_TIRTOS
INTIME_RTOS
WOLFSSL_NUCLEUS_1_2
WOLFSSL_APACHE_MYNEWT
WOLFSSL_ZEPHYR
WOLFSSL_TELIT_M2MB
WOLFSSL_SINGLE_THREADED

Our project uses the Renesas port of uITRON, but we cannot use the WOLFSSL_uITRON4 define because it pulls in declarations and code we do not have.

Our workaround is to create an empty file pthread.h in our project.

Can WolfSSL change the #else clause in the #if/#elif/#elif.../#else/#endif block in wolfssl/internal.h to allow users to not include <pthread.h>?

Go to forum: wolfSSL

6 Topic by Scoobi_FreeBSD

(1 replies, posted in wolfSSL)

When WolfSSL is configured to use the Atmel (now Microchip) hardware cryptographic library cryptoauthlib (WOLFSSL_ATMEL), the file #include's a deprecated file from the cryptoauthlib library - asf.h.

wolfcrypt/src/port/atmel/atmel.c:

#ifdef WOLFSSL_ATMEL
/* remap name conflicts */
#define Aes Aes_Remap
#define Gmac Gmac_Remap
#include "asf.h"
#undef Aes
#undef Gmac
#endif /* WOLFSSL_ATMEL */

"asf.h" apparently stands for Atmel's "Advanced Software Framework". I do not have this file in my cryptoauthlib library.

I'm not sure how to conditionally include "asf.h" based on the revision of cryptoauthlib or test for its presence, but I don't think "asf.h" is necessary to compile WolfSSL with Atmel support.  The above code block may be necessary if ASF is included in the user's cryptoauthlib (somehow).

Go to forum: wolfSSL