Repository navigation
TLSv1.3 cipher suites supported #42059
Copy link
Copy link
Closed as not planned
Labels
cryptoIssues and PRs related to the crypto subsystem.Issues and PRs related to the crypto subsystem.docIssues and PRs related to Node.js documentation.Issues and PRs related to Node.js documentation.questionIssues asking questions about Node.js.Issues asking questions about Node.js.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.tlsIssues and PRs related to the tls subsystem.Issues and PRs related to the tls subsystem.
Description
Affected URL(s)
https://nodejs.org/api/tls.html
Description of the problem
The page states:
Lines 360 to 370 in 53364a2
| There are only five TLSv1.3 cipher suites: | |
| * `'TLS_AES_256_GCM_SHA384'` | |
| * `'TLS_CHACHA20_POLY1305_SHA256'` | |
| * `'TLS_AES_128_GCM_SHA256'` | |
| * `'TLS_AES_128_CCM_SHA256'` | |
| * `'TLS_AES_128_CCM_8_SHA256'` | |
| The first three are enabled by default. The two `CCM`-based suites are supported | |
| by TLSv1.3 because they may be more performant on constrained systems, but they | |
| are not enabled by default since they offer less security. |
However executing tls.getCiphers() shows:
[
'aes128-gcm-sha256',
'aes128-sha',
'aes128-sha256',
'aes256-gcm-sha384',
'aes256-sha',
'aes256-sha256',
'dhe-psk-aes128-cbc-sha',
'dhe-psk-aes128-cbc-sha256',
'dhe-psk-aes128-gcm-sha256',
'dhe-psk-aes256-cbc-sha',
'dhe-psk-aes256-cbc-sha384',
'dhe-psk-aes256-gcm-sha384',
'dhe-psk-chacha20-poly1305',
'dhe-rsa-aes128-gcm-sha256',
'dhe-rsa-aes128-sha',
'dhe-rsa-aes128-sha256',
'dhe-rsa-aes256-gcm-sha384',
'dhe-rsa-aes256-sha',
'dhe-rsa-aes256-sha256',
'dhe-rsa-chacha20-poly1305',
'ecdhe-ecdsa-aes128-gcm-sha256',
'ecdhe-ecdsa-aes128-sha',
'ecdhe-ecdsa-aes128-sha256',
'ecdhe-ecdsa-aes256-gcm-sha384',
'ecdhe-ecdsa-aes256-sha',
'ecdhe-ecdsa-aes256-sha384',
'ecdhe-ecdsa-chacha20-poly1305',
'ecdhe-psk-aes128-cbc-sha',
'ecdhe-psk-aes128-cbc-sha256',
'ecdhe-psk-aes256-cbc-sha',
'ecdhe-psk-aes256-cbc-sha384',
'ecdhe-psk-chacha20-poly1305',
'ecdhe-rsa-aes128-gcm-sha256',
'ecdhe-rsa-aes128-sha',
'ecdhe-rsa-aes128-sha256',
'ecdhe-rsa-aes256-gcm-sha384',
'ecdhe-rsa-aes256-sha',
'ecdhe-rsa-aes256-sha384',
'ecdhe-rsa-chacha20-poly1305',
'psk-aes128-cbc-sha',
'psk-aes128-cbc-sha256',
'psk-aes128-gcm-sha256',
'psk-aes256-cbc-sha',
'psk-aes256-cbc-sha384',
'psk-aes256-gcm-sha384',
'psk-chacha20-poly1305',
'rsa-psk-aes128-cbc-sha',
'rsa-psk-aes128-cbc-sha256',
'rsa-psk-aes128-gcm-sha256',
'rsa-psk-aes256-cbc-sha',
'rsa-psk-aes256-cbc-sha384',
'rsa-psk-aes256-gcm-sha384',
'rsa-psk-chacha20-poly1305',
'srp-aes-128-cbc-sha',
'srp-aes-256-cbc-sha',
'srp-rsa-aes-128-cbc-sha',
'srp-rsa-aes-256-cbc-sha',
'tls_aes_128_ccm_8_sha256',
'tls_aes_128_ccm_sha256',
'tls_aes_128_gcm_sha256',
'tls_aes_256_gcm_sha384',
'tls_chacha20_poly1305_sha256'
]Notice how tls_aes_128_ccm_sha256 and tls_aes_128_ccm_8_sha256 is part of that list.
How can it then be true that the first example states they are not enabled?
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
cryptoIssues and PRs related to the crypto subsystem.Issues and PRs related to the crypto subsystem.docIssues and PRs related to Node.js documentation.Issues and PRs related to Node.js documentation.questionIssues asking questions about Node.js.Issues asking questions about Node.js.staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.tlsIssues and PRs related to the tls subsystem.Issues and PRs related to the tls subsystem.
Activity
richardlau commentedon Feb 20, 2022
I suspect this is either fixed by #41864 (yet to be released) or a documentation bug.
cc @nodejs/crypto
tniessen commentedon Feb 20, 2022
As stated in the documentation,
tls.getCiphers()returns the list of supported ciphers. But not all supported ciphers are enabled by default:node/doc/api/tls.md
Lines 276 to 278 in 53364a2
By default, the TLS 1.3
CCMciphers are disabled (look atcrypto.constants.defaultCoreCipherList). But they are supported, so you can manually enable them.thernstig commentedon Feb 21, 2022
@tniessen, thanks, that does make a bit more sense. I am thinking documentation could be more clear here, as it might not be immediately obvious. The key term
supportedis easy to misinterpret. To remedy this, I would recommend to add totls.getCiphers()some note stating that something likeIn addition, crypto also has the constant
crypto.constants.defaultCipherList, which shows the list of cipher suites configured (enabled/disabled etc.) following the format of openssl ciphers. This is not mentioned anywhere on https://nodejs.org/api/tls.html, but it is a good constant to know about. Should that be mentioned somewhere as well under Modifying the default TLS cipher suite?Last but not least, would it make sense to extend
tls.getCiphers()to allow for a parameter that could get the ciphers that ones is after in a more standarized way. For example I might change the--tls-cipher-listand then calltls.getCiphers(enabled)to only get enabled ciphers. In this case it works to usecrypto.constants.defaultCipherList, but having parameters togetCiphers()could also add possibilities like if I use--tls-min-v1.3there could be a parameter enum to only display the ones used by default. Maybe this would all become to unwieldy complex, but it's just a suggestion.Other changes I would make in the docs
First change
Current
Proposal
Reasoning
Each string like
TLS_AES_256_GCM_SHA384is a cipher suite in itself. So what is presented is a list of cipher suites.Second change
Rename heading
Modifying the default TLS cipher suitetoModifying the default TLS cipher suites. It is plural after all.thernstig commentedon Feb 21, 2022
How do I know which suites are enabled in the Node.js version I am using? For example, the default set of enabled cipher suites is mentioned to be:
If I execute this on
openssl(OpenSSL 1.1.1f 31 Mar 2020) on my machine I get:The reason for this is the
HIGHthat the default cipher suites list includes.But is there any way to view this in Node.js like this, i.e. the full suite of enabled ones? My suggestion above about
tls.getCiphers()might remedy this. But is there any way to get this list already now?tniessen commentedon Feb 21, 2022
I had the same thought yesterday and opened #42063 :) I'll look at additional documentation improvements later.
There is currently no way to expand the configured list into a list of all the cipher suites. If you need a specific list of cipher suites, you can configure it directly. The format is, unfortunately, specific to OpenSSL. Luckily, with the transition to TLS 1.3 that explicitly lists the few enabled cipher suites, this should not be an issue in the future.
thernstig commentedon Feb 21, 2022
Great if you can look at the rest of the doc suggestions :)
But there could be, if an API change was made to
tls.getCiphers()to accept parameters?What makes this even more confusing (in regards to enabled vs. disabled) is the output of these:
There is a large difference between these. Mind you, this is partly due to the openssl version I am using when viewing this, but since there is no way to show the full list of what
HIGHmeans in the context of the openssl lib Node.js was built with, I cannot know what will be allowed with my server.This is important for some projects, as they need export control to show the available TLS cipher suites used.
Is there absolutely no way for me to know this then from the Node.js version I am using, with any of the built-in commands?
thernstig commentedon Feb 21, 2022
To be more clear, the last post I made shows me that there are supported suites (via
tls.getciphers()) that do not even exist in the cipher suite list I get from myopenssl cipherscommand with the enabled suites in Node.js. This is... weird. How can suites be supported, but not exist in the enabled suites?(Could be due to different openssl lib versions, but the difference is rather big)
alaminhb commentedon Feb 22, 2022
doc: clarify supported versus enabled TLS ciphers
tniessen commentedon Feb 22, 2022
The two lists you posted are identical. Maybe I'm misunderstanding. Could you clarify this please?
thernstig commentedon Feb 23, 2022
@tniessen I had copy & pasted the wrong content into one of the examples. Updated now. Thanks for notifying me.
I also wrote #42077 in regards to additions to
tls.getCiphers().tniessen commentedon Feb 27, 2022
Because Node.js intentionally disables some supported cipher suites by default. For example, the two TLSv1.3 CCM cipher suites are both supported and disabled by default:
node/doc/api/tls.md
Lines 368 to 370 in 38626e7
Your browser might be doing the same thing (depending on the hardware), at least mine does.
doc: clarify supported versus enabled TLS ciphers
doc: clarify supported versus enabled TLS ciphers
doc: clarify supported versus enabled TLS ciphers
RopoMen commentedon Jan 11, 2024
This issue is for TLSv1.3 ciphers, but anyways. I noticed that current Node.js default cipher suite list contains these two ciphers:
ECDHE-RSA-AES256-SHA256andDHE-RSA-AES256-SHA384Which ARE NOT in the supported ciphers list through
tls.getCiphers()is this a documentation bug? Implementation bug? Or are those two ciphers added into the list for the future?Default cipher suite documentation states that
The default cipher suite included within Node.js has been carefully selected to reflect current security best practices and risk mitigation.if those are carefully selected then there should be reason why those two ciphers are added.github-actions commentedon Jun 25, 2026
This issue has been marked as stale due to 210 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
github-actions commentedon Jul 26, 2026
This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.