[v11.x backport] TLS1.3

[sam-github]

PRs included in this backort:

• Update openssl1.1.1b: Update openssl1.1.1b #26327, backported because openssl updates don't merge well, and always need backporting
• TLS1.3 support: TLS1.3 support #26209 (WIP), had to do some minor fixups to cherry-pick
• tls: revert default max to TLSv1.2: this is new, it reverts the semver-major change introduced in the previous commit
• tls: add debugging to native TLS code: tls: add debugging to native TLS code #26843, cherry-picked clean on top of TLS1.3 support
• doc: describe tls.DEFAULT_MIN_VERSION/_MAX_VERSION : doc: describe tls.DEFAULT_MIN_VERSION/_MAX_VERSION #26821, had to fix a minor conflict caused by tls: revert default max to TLSv1.2, which changed the default min/max from the values on master

• tls: support shared openssl 1.1.0: this is new, it adds back support for openssl 1.1.0
• tls: add --tls-min-v1.2 CLI switch: this is new, it adds a CLI switch to change the min protocol to v1.2

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• tests and/or benchmarks are included
• documentation is changed or added
• commit message follows commit guidelines

[nodejs-github-bot]

@sam-github build started: https://ci.nodejs.org/blue/organizations/jenkins/node-test-pull-request-lite-pipeline/detail/node-test-pull-request-lite-pipeline/3078/pipeline

[sam-github]

@targos, do you have any suggestions as to how to backport a set of dependent PRs to 11.x?

TLS1.3 depends on openssl1.1.1b, as well as the #25093 and #24729, see #24729 (comment)

Can I just pick them all onto this branch as I find necessary, or will that make things hard for you?

I could also do the backports in series, but that is made difficult unless they are pretty promptly cherry-picked onto v11.x-staging, because I have to float the commits in a stand-alone PR-branch, but I also need them in this PR-branch so I can keep working.

I'm not sure what the normal way of doing this is.

Btw, the openssl1.1.1b part of this PR could be cherry-picked to #26949 right now, I believe. Should I PR that immediately? Its only a backport because we don't merge openssl updates back, we re-do the source commit and the config regeneration step from scratch.

[rvagg]

@sam-github is this just "Drafting" because it doesn't have those dependent pieces? Other than that it's a straight backport of 1.3?

[sam-github]

Remaining work (that I know about!):

1. Fix the test failures, I'm working through them. 7 of the tests are because of the missing .code property, it looks like, thus the dependent backports. Still need to look at the other 3.
2. Once the tests pass, I need to push one more commit, to change the TLS default max back to TLS1.2, and then make sure the tests still pass.

[sam-github]

@rvagg And I forgot to answer

Other than that it's a straight backport of 1.3?

So far, yes. Some conflict resolution during cherry pick, but nothing remarkable. The change to the default TLS max is the only thing I expect to be different, and I hope it won't affect the test suite too much.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/21991/

[sam-github]

Passes locally, both with TLS1.3 as the default max, and with TLS1.2 as the default max. Lets see what CI thinks.

Depends on:

• [v11.x backport] src: add .code and SSL specific error properties #26953
• [v11.x backport] src: add .code and SSL specific error properties #26953
  which are in this branch. They can rebased away once above 2 backports land.

[targos]

@sam-github

@targos, do you have any suggestions as to how to backport a set of dependent PRs to 11.x?

Whatever is easier for you. I like when multiple backports are bundled in the same PR, so from my PoV you could close the other backport PRs and we land everything when this is ready.

[mscdex]

Does this mean v11.x will no longer build against shared OpenSSL 1.1.0?

[sam-github]

@mscdex ATM it does, but I suspect losing support for shared openssl 1.1.0 is not acceptable as semver-minor, would you agree?

I'm going to try to fix that, I assume it will take only a few ifdefs in c++, and then a whole lot more checks in the test suites for TLS1.3 support.

Actually attempting to use 1.1.1 features when node.js when its built against 1.1.0 will not go well, which is expected (I guess) and we don't document what features are 1.1.1 specific. Is there any way to give a heads up to distributors? Or (@refack?) is there a way at ./configure time to warn that the --shared-openssl options are being used, but the shared openssl version is < openssl 1.1.1b, just so people know that the build will not be fully functional?

I'm not sure why it is that we ever allowed building against a shared library that is not the same version as the currently included openssl version. I'd speculate that 1.1.0 and 1.0.2 were so similar it didn't matter much, though even there I'd think that 1.1.0 would have had something that a node API user would have noticed.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/22019/

[refack]

Seems like this and #27132 were the only PRs affected 😌.
Sorry for the noise.

[refack]

If anyone is interested https://gist.github.com/refack/1ec020607baa346e9265554646274de5 is a pre-push hook to block git from creating or deleting branches on a /nodejs/ repo.

[sam-github]

WIP backport: #27432