Error: ERR_OSSL_EVP_UNSUPPORTED when sending a message to SQS in Node.js 18 Lambda with custom OpenSSL layer

[SantosC95]

Checkboxes for prior research

• I've gone through Developer Guide and API reference
• I've checked AWS Forums and StackOverflow.
• I've searched for previous similar issues and didn't find any solution.

Describe the bug

Summary

I am encountering an ERR_OSSL_EVP_UNSUPPORTED error when sending a message to SQS in a Node.js 18 Lambda function. Despite the error, the message is still successfully pushed into the queue. The Lambda function is running in a FIPS-compliant GovCloud environment and has a custom OpenSSL layer (3.0.8).

Error Details

error:0308010C:digital envelope routines::unsupported
    at new Hash (node:internal/crypto/hash:69:19)
    at createHash (node:crypto:133:10)
    at Hash.reset (/var/runtime/node_modules/@aws-sdk/node_modules/@smithy/hash-node/dist-cjs/index.js:23:39)
    at new Hash (/var/runtime/node_modules/@aws-sdk/node_modules/@smithy/hash-node/dist-cjs/index.js:12:14)
    at /var/runtime/node_modules/@aws-sdk/middleware-sdk-sqs/dist-cjs/send-message.js:9:18
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async /var/runtime/node_modules/@aws-sdk/middleware-logger/dist-cjs/loggerMiddleware.js:7:26)
    at async InitQueue.sendMessage (/var/task/lib/services/commons/qrveyQueue.js:72:25)
    at async InitQueue.sendMessage (/var/task/lib/services/Init/initQueue.js:27:16)
    at async Init.runSynchronousInitJob (/var/task/lib/services/Init/index.js:708:9) {
  opensslErrorStack: [ 'error:03000086:digital envelope routines::initialization error' ],
  library: 'digital envelope routines',
  reason: 'unsupported',
  code: 'ERR_OSSL_EVP_UNSUPPORTED'
}

We believe the line of code where the error occurs is here.

Environment Details

• Node.js version: 18.x
• Lambda architecture: x86_64
• Environment: AWS GovCloud (FIPS compliant)
• OpenSSL Layer Version: 3.0.8

SDK version number

@aws-sdk/middleware-sdk

Which JavaScript Runtime is this issue in?

Node.js

Details of the browser/Node.js/ReactNative version

Node.js 18.x

Reproduction Steps

1. Create a Lambda function using Node.js 18.x runtime.
2. Configure the Lambda function to run in a FIPS-compliant GovCloud environment.
3. Attach a custom OpenSSL layer (version 3.0.8) to the Lambda function.
4. Attempt to send a message to an SQS queue.

Observed Behavior

• The message is successfully pushed into the SQS queue.
• The error is still thrown despite the successful message push.

Expected Behavior

No error should be thrown when sending a message to SQS.

Possible Solution

No response

Additional Information/Context

Please let me know if any additional information is needed.

[aBurmeseDev]

Hi @SantosC95 - thanks for reaching out and apology for the wait.

Can you please provide a minimal reproducible code without any sensitive information? I couldn't find any similar reports to this and wasn't able to reproduce it on my end. Any additional details that you can provide would be helpful for us.

Here're issues I think is related:

• How to build Node.js binary with FIPS-compliant OpenSSL? nodejs/help#753
• Issue when enabling fips mode on the SDK #4965
• https://stackoverflow.com/questions/69962209/what-is-openssl-legacy-provider-in-node-js-v17

[SantosC95]

Hi @aBurmeseDev

Sorry for the late response,

Here you have a code snippet we already shared with the AWS tech support team:

const { SQSClient, SendMessageCommand } = require('@aws-sdk/client-sqs');

const sqsClient = new SQSClient({ region: 'us-east-1' });

exports.handler = async (event) => {
    const params = {
        QueueUrl: '<<A-valid-SQS-url>>',
        MessageBody: JSON.stringify({
            message: 'Hello from Lambda!',
        }),
    };
    try {
        const data = await sqsClient.send(new SendMessageCommand(params));
        console.log('Message sent successfully:', data.MessageId);
        return {
            statusCode: 200,
            body: JSON.stringify({ messageId: data.MessageId }),
        };
    } catch (error) {
        console.error('Error sending message:', error);
        return {
            statusCode: 500,
            body: JSON.stringify({ error }),
        };
    }
};

Environment variables:

OPENSSL_CONF=/opt/ssl/openssl_fips.cnf
OPENSSL_MODULES=/opt/openssl/lib64/ossl-modules
LD_LIBRARY_PATH=/opt/openssl/lib64:$LD_LIBRARY_PATH

Please, use the attached .zip as a lambda layer.
qrvey_fips_layer.zip

Thanks for your help.

[Sepehr-Qrvey]

Hi @aBurmeseDev,

We found the issue was due to the md5 checksum that the SQS SDK uses, since md5 is not a FIPS-supported algorithm.

Related issues:
Aws::SQS::Client in GovCloud fails for use of MD5 -> disabled for fips aws/aws-cli#9032
MD5 checksum crash in AWS SQS receive messages #4717

Seems like an md5: false option was added to the v3 SQS SDK in April, but we feel that the checksum should support - or even use by default - a non-md5 algorithm as well, since this option only disables the checksum altogether.

In addition, for readers in the near future, the md5: false option is not available yet in the GovCloud Lambda environment because the default version of the SDK that is present in the node.js 18.x GovCloud Lambda runtime is older than April. You will need to include a newer version of the SDK in a layer to be able to use this option.

[aBurmeseDev]

@Sepehr-Qrvey - thanks for sharing!

Seems like an md5: false option was added to the v3 SQS SDK in April, but we feel that the checksum should support - or even use by default - a non-md5 algorithm as well, since this option only disables the checksum altogether.

This's correct, and is documented in our UPGRADING.md.

To skip computation of MD5 checksums of message bodies, set md5=false on the configuration object. Otherwise, by default the SDK will calculate the checksum for sending messages, as well as validating the checksum for retrieved messages.

// Example: skip md5 checksum in SQS.
import { SQS } from "@aws-sdk/client-sqs";

new SQS({
  md5: false, // Note: only available in v3.547.0 and higher.
});

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs and link to relevant comments in this thread.