This vulnerability exposes encrypted data to a number of attacks whose goal is to recover the plaintext.
Why is this an issue?
Encryption algorithms are essential for protecting sensitive information and ensuring secure communications in a variety of domains. They are used
for several important reasons:
- Confidentiality, privacy, and intellectual property protection
- Security during transmission or on storage devices
- Data integrity, general trust, and authentication
When selecting encryption algorithms, tools, or combinations, you should also consider two things:
- No encryption is unbreakable.
- The strength of an encryption algorithm is usually measured by the effort required to crack it within a reasonable time frame.
For these reasons, as soon as cryptography is included in a project, it is important to choose encryption algorithms that are considered strong and
secure by the cryptography community.
To provide communication security over a network, SSL and TLS are generally used. However, it is important to note that the following protocols are
all considered weak by the cryptographic community, and are officially deprecated:
- SSL versions 1.0, 2.0 and 3.0
- TLS versions 1.0 and 1.1
When these unsecured protocols are used, it is best practice to expect a breach: that a user or organization with malicious intent will perform
mathematical attacks on this data after obtaining it by other means.
What is the potential impact?
After retrieving encrypted data and performing cryptographic attacks on it on a given timeframe, attackers can recover the plaintext that
encryption was supposed to protect.
Depending on the recovered data, the impact may vary.
Below are some real-world scenarios that illustrate the potential impact of an attacker exploiting the vulnerability.
Additional attack surface
By modifying the plaintext of the encrypted message, an attacker may be able to trigger additional vulnerabilities in the code. An attacker can
further exploit a system to obtain more information.
Encrypted values are often considered trustworthy because it would not be possible for a
third party to modify them under normal circumstances.
Breach of confidentiality and privacy
When encrypted data contains personal or sensitive information, its retrieval by an attacker can lead to privacy violations, identity theft,
financial loss, reputational damage, or unauthorized access to confidential systems.
In this scenario, the company, its employees, users, and partners could be seriously affected.
The impact is twofold, as data breaches and exposure of encrypted data can undermine trust in the organization, as customers, clients and
stakeholders may lose confidence in the organization’s ability to protect their sensitive data.
Legal and compliance issues
In many industries and locations, there are legal and compliance requirements to protect sensitive data. If encrypted data is compromised and the
plaintext can be recovered, companies face legal consequences, penalties, or violations of privacy laws.
How to fix it in Node.js
Code examples
Noncompliant code example
NodeJs offers multiple ways to set weak TLS protocols. For https and tls, these options are used and are used in other third-party libraries as
well.
The first is secureProtocol:
const https = require('node:https');
const tls = require('node:tls');
let options = {
secureProtocol: 'TLSv1_method' // Noncompliant
};
let req = https.request(options, (res) => { });
let socket = tls.connect(443, "www.example.com", options, () => { });
The second is the combination of minVersion and maxVerison. Note that they cannot be specified along with the
secureProtocol option:
const https = require('node:https');
const tls = require('node:tls');
let options = {
minVersion: 'TLSv1.1', // Noncompliant
maxVersion: 'TLSv1.2'
};
let req = https.request(options, (res) => { });
let socket = tls.connect(443, "www.example.com", options, () => { });
And secureOptions, which in this example instructs the OpenSSL protocol to turn off some algorithms altogether. In general, this
option might trigger side effects and should be used carefully, if used at all.
const https = require('node:https');
const tls = require('node:tls');
const constants = require('node:crypto'):
let options = {
secureOptions:
constants.SSL_OP_NO_SSLv2
| constants.SSL_OP_NO_SSLv3
| constants.SSL_OP_NO_TLSv1
}; // Noncompliant
let req = https.request(options, (res) => { });
let socket = tls.connect(443, "www.example.com", options, () => { });
Compliant solution
const https = require('node:https');
const tls = require('node:tls');
let options = {
secureProtocol: 'TLSv1_2_method'
};
let req = https.request(options, (res) => { });
let socket = tls.connect(443, "www.example.com", options, () => { });
const https = require('node:https');
const tls = require('node:tls');
let options = {
minVersion: 'TLSv1.2',
maxVersion: 'TLSv1.2'
};
let req = https.request(options, (res) => { });
let socket = tls.connect(443, "www.example.com", options, () => { });
Here, the goal is to turn on only TLSv1.2 and higher, by turning off all lower versions:
const https = require('node:https');
const tls = require('node:tls');
let options = {
secureOptions:
constants.SSL_OP_NO_SSLv2
| constants.SSL_OP_NO_SSLv3
| constants.SSL_OP_NO_TLSv1
| constants.SSL_OP_NO_TLSv1_1
};
let req = https.request(options, (res) => { });
let socket = tls.connect(443, "www.example.com", options, () => { });
How does this work?
As a rule of thumb, by default you should use the cryptographic algorithms and mechanisms that are considered strong by the cryptographic
community.
The best choices at the moment are the following.
Use TLS v1.2 or TLS v1.3
Even though TLS V1.3 is available, using TLS v1.2 is still considered good and secure practice by the cryptography community.
The use of TLS v1.2 ensures compatibility with a wide range of platforms and enables seamless communication between different systems that do not
yet have TLS v1.3 support.
The only drawback depends on whether the framework used is outdated: its TLS v1.2 settings may enable older and insecure cipher suites that are
deprecated as insecure.
On the other hand, TLS v1.3 removes support for older and weaker cryptographic algorithms, eliminates known vulnerabilities from previous TLS
versions, and improves performance.
How to fix it in AWS CDK
Code examples
Noncompliant code example
import { aws_apigateway as agw } from 'aws-cdk-lib';
new agw.DomainName(this, 'Example', {
certificate: certificate,
domainName: domainName,
securityPolicy: agw.SecurityPolicy.TLS_1_0, // Noncompliant
});
The resource CfnDomain uses a weak TLS security policy, by default.
import { aws_opensearchservice as os } from 'aws-cdk-lib';
new os.CfnDomain(this, 'Example', {
domainEndpointOptions: {
enforceHttps: true,
},
}); // Noncompliant
Compliant solution
import { aws_apigateway as agw } from 'aws-cdk-lib';
new agw.DomainName(this, 'Example', {
certificate: certificate,
domainName: domainName,
securityPolicy: agw.SecurityPolicy.TLS_1_2,
});
import { aws_opensearchservice as os } from 'aws-cdk-lib';
new os.CfnDomain(this, 'Example', {
domainEndpointOptions: {
enforceHttps: true,
tlsSecurityPolicy: 'Policy-Min-TLS-1-2-2019-07',
},
});
How does this work?
As a rule of thumb, by default you should use the cryptographic algorithms and mechanisms that are considered strong by the cryptographic
community.
The best choices at the moment are the following.
Use TLS v1.2 or TLS v1.3
Even though TLS V1.3 is available, using TLS v1.2 is still considered good and secure practice by the cryptography community.
The use of TLS v1.2 ensures compatibility with a wide range of platforms and enables seamless communication between different systems that do not
yet have TLS v1.3 support.
The only drawback depends on whether the framework used is outdated: its TLS v1.2 settings may enable older and insecure cipher suites that are
deprecated as insecure.
On the other hand, TLS v1.3 removes support for older and weaker cryptographic algorithms, eliminates known vulnerabilities from previous TLS
versions, and improves performance.
Resources
Articles & blog posts
Standards
