crypto: don't disable TLS 1.3 without suites #43427
Conversation
|
Review requested:
|
nodejs-github-bot
added
needs-ci
|
A few tests will require fixes.... but it would be nice to have feedback especially when these ciphers are set externally to node itself. |
|
I've fixed some of the unit tests now but will finish the rest next week. Mostly it's just involves clamping the maxVersion to TLSv1.2 when there are no TLS 1.3 cipher suites set. |
|
This should now pass CI. Fix in |
In the manual page, there is a statement that ciphersuites contain explicit default settings - all TLS 1.3 ciphersuites enabled. In node, we assume that an empty setting mean no ciphersuites and we disable TLS 1.3. A correct approach to disabling TLS 1.3 is to disable TLS 1.3 and by not override the default ciphersuits with an empty string. So, only override OpenSSL's TLS 1.3 ciphersuites with an explicit list of ciphers. If none are acceptable, the correct approach is to disable TLS 1.3 instead elsewhere. Fixes: nodejs#43419
github-actions
bot
removed
the
request-ci
mcollina
added
commit-queue
nodejs-github-bot
removed
the
commit-queue
Commit Queue failed- Loading data for nodejs/node/pull/43427 ✔ Done loading data for nodejs/node/pull/43427 ----------------------------------- PR info ------------------------------------ Title crypto: don't disable TLS 1.3 without suites (#43427) ⚠ Could not retrieve the email or name of the PR author's from user's GitHub profile! Branch AdamMajer:ciphersuites -> nodejs:main Labels tls, commit-queue-squash Commits 1 - crypto: don't disable TLS 1.3 without suites Committers 1 - Adam Majer PR-URL: https://github.com/nodejs/node/pull/43427 Fixes: https://github.com/nodejs/node/issues/43419 Reviewed-By: Matteo Collina Reviewed-By: Paolo Insogna Reviewed-By: James M Snell ------------------------------ Generated metadata ------------------------------ PR-URL: https://github.com/nodejs/node/pull/43427 Fixes: https://github.com/nodejs/node/issues/43419 Reviewed-By: Matteo Collina Reviewed-By: Paolo Insogna Reviewed-By: James M Snell -------------------------------------------------------------------------------- ⚠ Commits were pushed since the last review: ⚠ - crypto: don't disable TLS 1.3 without suites ℹ This PR was created on Tue, 14 Jun 2022 15:11:49 GMT ✔ Approvals: 3 ✔ - Matteo Collina (@mcollina) (TSC): https://github.com/nodejs/node/pull/43427#pullrequestreview-1006059888 ✔ - Paolo Insogna (@ShogunPanda): https://github.com/nodejs/node/pull/43427#pullrequestreview-1006070148 ✔ - James M Snell (@jasnell) (TSC): https://github.com/nodejs/node/pull/43427#pullrequestreview-1006073727 ✔ Last GitHub CI successful ℹ Last Full PR CI on 2022-06-24T23:13:05Z: https://ci.nodejs.org/job/node-test-pull-request/44842/ - Querying data for job/node-test-pull-request/44842/ ✔ Last Jenkins CI successful -------------------------------------------------------------------------------- ✔ Aborted `git node land` session in /home/runner/work/node/node/.ncuhttps://github.com/nodejs/node/actions/runs/2560676043 |
nodejs-github-bot
added
the
commit-queue-failed
mcollina
added
commit-queue
nodejs-github-bot
removed
the
commit-queue
|
Landed in 9cde7a0 |
In the manual page, there is a statement that ciphersuites contain explicit default settings - all TLS 1.3 ciphersuites enabled. In node, we assume that an empty setting mean no ciphersuites and we disable TLS 1.3. A correct approach to disabling TLS 1.3 is to disable TLS 1.3 and by not override the default ciphersuits with an empty string. So, only override OpenSSL's TLS 1.3 ciphersuites with an explicit list of ciphers. If none are acceptable, the correct approach is to disable TLS 1.3 instead elsewhere. Fixes: #43419 PR-URL: #43427 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: James M Snell <[email protected]>
In the manual page, there is a statement that ciphersuites contain explicit default settings - all TLS 1.3 ciphersuites enabled. In node, we assume that an empty setting mean no ciphersuites and we disable TLS 1.3. A correct approach to disabling TLS 1.3 is to disable TLS 1.3 and by not override the default ciphersuits with an empty string. So, only override OpenSSL's TLS 1.3 ciphersuites with an explicit list of ciphers. If none are acceptable, the correct approach is to disable TLS 1.3 instead elsewhere. Fixes: #43419 PR-URL: #43427 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: James M Snell <[email protected]>
|
OpenSSL docs for reference:
Node.js' TLS cipher list covers all TLS versions (in contrary to the OpenSSL definition). With this PR, if we specify a single TLSv1.2 ciphersuite (regardless whether through The change is quite breaking, so I believe this should have been released in the next major release instead. |
|
This is correct - the TLSv1.3 ciphersuites are for TLSv1.3, so the correct way is to set max TLS version to 1.2 if you only want TLS 1.2 used. This fix breaks the assumption that TLSv1.3 should be disabled when cipher suites are not explicitly present because TLSv1.3 has a default set of cipher suites already. This was not the case for TLSv1.2 and prior. But at the same time, the way that cipher suites were selected prior to this, having disabled TLSv1.3 whenever distros used crypto policies or other OpenSSL based ciphers - this is a bug. For example, setting ciphers list to Personally, I will have to backport this to our nodejs16 irrespective if it gets backported here. I believe that disabling TLSv1.3 by accident is worse than having it enabled by accident 😉 |
That is a separate case and should not (I believe) be confused with providing a single ciphersuite. I think the problem we have here is that a single option is used to control both <TLSv1.3 and TLSv1.3 ciphersuites. OpenSSL separates them and I believe that Node.js should too 🤔 |
|
Providing different options now for both would be even larger change. Upstream has provided the 2nd option because they didn't want people to accidentally disable their TLSv1.3 support by not supplying TLS1.3 ciphers ;) openssl/openssl#11899 (comment) In Node, the difference between cipher set and cipher suite is whether it uses standard names or not. So, OpenSSL surprises :-) So, having a single command line parameter for both makes sense, provided that this OpenSSL feature is not a bug 😆 Now, for the possible reason why TLSv1.3 was disabled in node when no ciphersuites were selected, is, This will work if we explicitly only permit TLSv1.2, And it makes sense because TLS Protocol version negotiation happens prior to cipher negotiation. And this was already found 2 years ago, adrienverge/openfortivpn#687 (comment) Of course, the core of the problem is that TLSv1.3 should not be disabled if cipher suites are not specified. This PR fixes this problem and restores upstream behaviour (as per OpenSSL's explicit design decision). This is why it should not be viewed as a major feature change and more of a bug fix. |
Hence the need for two different options.
It's not a TLSv1.3 ciphersuite.
Their explicit design decision was to have two different options, not a single one. Despite this PR being a bug fix, it's a major breaking change. I had code that was relying on the previous behavior and it stopped working with this PR. |
|
Sure, but despite what it says, openssl is still setting TLSv1.2 cipher with ciphersuite option, as I demonstrated. 🤷
Did you expect that TLSv1.3 would be disabled implicitly if you didn't specify the ciphersuite in a cipher set? That's the only thing that is really changed here. |
It was just implemented like that:
That doesn't mean the option should be misused, no?
Correct. I expected that because Node.js' option manages both <TLSv1.3 and TLSv1.3. Autofilling other ciphers where I explicitly set just one sounds like magic behavior to me.
That works, however that is a breaking change since it requires a change in my code. To sum up, since this has already landed I'm okay with this change ~ maybe someday we'll have a more strict way to set ciphers :) |
In the manual page, there is a statement that ciphersuites contain explicit default settings - all TLS 1.3 ciphersuites enabled. In node, we assume that an empty setting mean no ciphersuites and we disable TLS 1.3. A correct approach to disabling TLS 1.3 is to disable TLS 1.3 and by not override the default ciphersuits with an empty string. So, only override OpenSSL's TLS 1.3 ciphersuites with an explicit list of ciphers. If none are acceptable, the correct approach is to disable TLS 1.3 instead elsewhere. Fixes: #43419 PR-URL: #43427 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: James M Snell <[email protected]>
In the manual page, there is a statement that ciphersuites contain explicit default settings - all TLS 1.3 ciphersuites enabled. In node, we assume that an empty setting mean no ciphersuites and we disable TLS 1.3. A correct approach to disabling TLS 1.3 is to disable TLS 1.3 and by not override the default ciphersuits with an empty string. So, only override OpenSSL's TLS 1.3 ciphersuites with an explicit list of ciphers. If none are acceptable, the correct approach is to disable TLS 1.3 instead elsewhere. Fixes: nodejs/node#43419 PR-URL: nodejs/node#43427 Reviewed-By: Matteo Collina <[email protected]> Reviewed-By: Paolo Insogna <[email protected]> Reviewed-By: James M Snell <[email protected]>
In the manual page, there is a stement that ciphersuites contain
explicit default settings - all TLS 1.3 ciphersuites are available.
In node, we assume that an empty setting mean no ciphersuites and
we disable TLS 1.3. A correct approach to disabling TLS 1.3 is to
disable TLS 1.3 and by not override the default ciphersuits
with an empty string.
So, only override OpenSSL's TLS 1.3 ciphersuites with an explicit
list of ciphers. If none are acceptible, the correct approach is
to disable TLS 1.3 instead elsewhere.
Fixes: #43419