tls: introduce client 'session' event #25831

sam-github · 2019-01-30T22:04:12Z

OpenSSL has supported async notification of sessions and tickets since
1.1.0 using SSL_CTX_sess_set_new_cb(), for all versions of TLS. Using
the async API is optional for TLS1.2 and below, but for TLS1.3 it will
be mandatory. Future-proof applications should start to use async
notification immediately. In the future, for TLS1.3, applications that
don't use the async API will silently, but gracefully, fail to resume
sessions and instead do a full handshake.

See: https://wiki.openssl.org/index.php/TLS1.3#Sessions

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 · 2019-01-30T22:04:14Z

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

sam-github · 2019-01-30T22:05:08Z

@nodejs/crypto

indutny

LGTM

doc/api/tls.md

OpenSSL has supported async notification of sessions and tickets since 1.1.0 using SSL_CTX_sess_set_new_cb(), for all versions of TLS. Using the async API is optional for TLS1.2 and below, but for TLS1.3 it will be mandatory. Future-proof applications should start to use async notification immediately. In the future, for TLS1.3, applications that don't use the async API will silently, but gracefully, fail to resume sessions and instead do a full handshake. See: https://wiki.openssl.org/index.php/TLS1.3#Sessions

OpenSSL has supported async notification of sessions and tickets since 1.1.0 using SSL_CTX_sess_set_new_cb(), for all versions of TLS. Using the async API is optional for TLS1.2 and below, but for TLS1.3 it will be mandatory. Future-proof applications should start to use async notification immediately. In the future, for TLS1.3, applications that don't use the async API will silently, but gracefully, fail to resume sessions and instead do a full handshake. See: https://wiki.openssl.org/index.php/TLS1.3#Sessions PR-URL: nodejs#25831 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Fedor Indutny <[email protected]>

sam-github · 2019-02-02T03:07:31Z

Landed in 0f8e8f7

OpenSSL has supported async notification of sessions and tickets since 1.1.0 using SSL_CTX_sess_set_new_cb(), for all versions of TLS. Using the async API is optional for TLS1.2 and below, but for TLS1.3 it will be mandatory. Future-proof applications should start to use async notification immediately. In the future, for TLS1.3, applications that don't use the async API will silently, but gracefully, fail to resume sessions and instead do a full handshake. See: https://wiki.openssl.org/index.php/TLS1.3#Sessions PR-URL: #25831 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Fedor Indutny <[email protected]>

This introduces TLS1.3 support and makes it the default max protocol, but also supports CLI/NODE_OPTIONS switches to disable it if necessary. TLS1.3 is a major update to the TLS protocol, with many security enhancements. It should be preferred over TLS1.2 whenever possible. TLS1.3 is different enough that even though the OpenSSL APIs are technically API/ABI compatible, that when TLS1.3 is negotiated, the timing of protocol records and of callbacks broke assumptions hard-coded into the 'tls' module. This change introduces no API incompatibilities when TLS1.2 is negotiated. It is the intention that it be backported to current and LTS release lines with the default maximum TLS protocol reset to 'TLSv1.2'. This will allow users of those lines to explicitly enable TLS1.3 if they want. API incompatibilities between TLS1.2 and TLS1.3 are: - Renegotiation is not supported by TLS1.3 protocol, attempts to call `.renegotiate()` will always fail. - Compiling against a system OpenSSL lower than 1.1.1 is no longer supported (OpenSSL-1.1.0 used to be supported with configure flags). - Variations of `conn.write('data'); conn.destroy()` have undefined behaviour according to the streams API. They may or may not send the 'data', and may or may not cause a ERR_STREAM_DESTROYED error to be emitted. This has always been true, but conditions under which the write suceeds is slightly but observably different when TLS1.3 is negotiated vs when TLS1.2 or below is negotiated. - If TLS1.3 is negotiated, and a server calls `conn.end()` in its 'secureConnection' listener without any data being written, the client will not receive session tickets (no 'session' events will be emitted, and `conn.getSession()` will never return a resumable session). - The return value of `conn.getSession()` API may not return a resumable session if called right after the handshake. The effect will be that clients using the legacy `getSession()` API will resume sessions if TLS1.2 is negotiated, but will do full handshakes if TLS1.3 is negotiated. See nodejs#25831 for more information.

This introduces TLS1.3 support and makes it the default max protocol, but also supports CLI/NODE_OPTIONS switches to disable it if necessary. TLS1.3 is a major update to the TLS protocol, with many security enhancements. It should be preferred over TLS1.2 whenever possible. TLS1.3 is different enough that even though the OpenSSL APIs are technically API/ABI compatible, that when TLS1.3 is negotiated, the timing of protocol records and of callbacks broke assumptions hard-coded into the 'tls' module. This change introduces no API incompatibilities when TLS1.2 is negotiated. It is the intention that it be backported to current and LTS release lines with the default maximum TLS protocol reset to 'TLSv1.2'. This will allow users of those lines to explicitly enable TLS1.3 if they want. API incompatibilities between TLS1.2 and TLS1.3 are: - Renegotiation is not supported by TLS1.3 protocol, attempts to call `.renegotiate()` will always fail. - Compiling against a system OpenSSL lower than 1.1.1 is no longer supported (OpenSSL-1.1.0 used to be supported with configure flags). - Variations of `conn.write('data'); conn.destroy()` have undefined behaviour according to the streams API. They may or may not send the 'data', and may or may not cause a ERR_STREAM_DESTROYED error to be emitted. This has always been true, but conditions under which the write suceeds is slightly but observably different when TLS1.3 is negotiated vs when TLS1.2 or below is negotiated. - If TLS1.3 is negotiated, and a server calls `conn.end()` in its 'secureConnection' listener without any data being written, the client will not receive session tickets (no 'session' events will be emitted, and `conn.getSession()` will never return a resumable session). - The return value of `conn.getSession()` API may not return a resumable session if called right after the handshake. The effect will be that clients using the legacy `getSession()` API will resume sessions if TLS1.2 is negotiated, but will do full handshakes if TLS1.3 is negotiated. See #25831 for more information. PR-URL: #26209 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rod Vagg <[email protected]>

This introduces TLS1.3 support and makes it the default max protocol, but also supports CLI/NODE_OPTIONS switches to disable it if necessary. TLS1.3 is a major update to the TLS protocol, with many security enhancements. It should be preferred over TLS1.2 whenever possible. TLS1.3 is different enough that even though the OpenSSL APIs are technically API/ABI compatible, that when TLS1.3 is negotiated, the timing of protocol records and of callbacks broke assumptions hard-coded into the 'tls' module. This change introduces no API incompatibilities when TLS1.2 is negotiated. It is the intention that it be backported to current and LTS release lines with the default maximum TLS protocol reset to 'TLSv1.2'. This will allow users of those lines to explicitly enable TLS1.3 if they want. API incompatibilities between TLS1.2 and TLS1.3 are: - Renegotiation is not supported by TLS1.3 protocol, attempts to call `.renegotiate()` will always fail. - Compiling against a system OpenSSL lower than 1.1.1 is no longer supported (OpenSSL-1.1.0 used to be supported with configure flags). - Variations of `conn.write('data'); conn.destroy()` have undefined behaviour according to the streams API. They may or may not send the 'data', and may or may not cause a ERR_STREAM_DESTROYED error to be emitted. This has always been true, but conditions under which the write suceeds is slightly but observably different when TLS1.3 is negotiated vs when TLS1.2 or below is negotiated. - If TLS1.3 is negotiated, and a server calls `conn.end()` in its 'secureConnection' listener without any data being written, the client will not receive session tickets (no 'session' events will be emitted, and `conn.getSession()` will never return a resumable session). - The return value of `conn.getSession()` API may not return a resumable session if called right after the handshake. The effect will be that clients using the legacy `getSession()` API will resume sessions if TLS1.2 is negotiated, but will do full handshakes if TLS1.3 is negotiated. See nodejs#25831 for more information. PR-URL: nodejs#26209 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rod Vagg <[email protected]>

This introduces TLS1.3 support and makes it the default max protocol, but also supports CLI/NODE_OPTIONS switches to disable it if necessary. TLS1.3 is a major update to the TLS protocol, with many security enhancements. It should be preferred over TLS1.2 whenever possible. TLS1.3 is different enough that even though the OpenSSL APIs are technically API/ABI compatible, that when TLS1.3 is negotiated, the timing of protocol records and of callbacks broke assumptions hard-coded into the 'tls' module. This change introduces no API incompatibilities when TLS1.2 is negotiated. It is the intention that it be backported to current and LTS release lines with the default maximum TLS protocol reset to 'TLSv1.2'. This will allow users of those lines to explicitly enable TLS1.3 if they want. API incompatibilities between TLS1.2 and TLS1.3 are: - Renegotiation is not supported by TLS1.3 protocol, attempts to call `.renegotiate()` will always fail. - Compiling against a system OpenSSL lower than 1.1.1 is no longer supported (OpenSSL-1.1.0 used to be supported with configure flags). - Variations of `conn.write('data'); conn.destroy()` have undefined behaviour according to the streams API. They may or may not send the 'data', and may or may not cause a ERR_STREAM_DESTROYED error to be emitted. This has always been true, but conditions under which the write suceeds is slightly but observably different when TLS1.3 is negotiated vs when TLS1.2 or below is negotiated. - If TLS1.3 is negotiated, and a server calls `conn.end()` in its 'secureConnection' listener without any data being written, the client will not receive session tickets (no 'session' events will be emitted, and `conn.getSession()` will never return a resumable session). - The return value of `conn.getSession()` API may not return a resumable session if called right after the handshake. The effect will be that clients using the legacy `getSession()` API will resume sessions if TLS1.2 is negotiated, but will do full handshakes if TLS1.3 is negotiated. See #25831 for more information. Backport-PR-URL: #26951 PR-URL: #26209 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rod Vagg <[email protected]>

OpenSSL has supported async notification of sessions and tickets since 1.1.0 using SSL_CTX_sess_set_new_cb(), for all versions of TLS. Using the async API is optional for TLS1.2 and below, but for TLS1.3 it will be mandatory. Future-proof applications should start to use async notification immediately. In the future, for TLS1.3, applications that don't use the async API will silently, but gracefully, fail to resume sessions and instead do a full handshake. See: https://wiki.openssl.org/index.php/TLS1.3#Sessions PR-URL: nodejs#25831 Reviewed-By: Anna Henningsen <[email protected]> Reviewed-By: Fedor Indutny <[email protected]>

nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. lib / src Issues and PRs related to general changes in the lib or src directory. labels Jan 30, 2019

sam-github requested review from shigeki and bnoordhuis January 30, 2019 22:04

addaleax added tls Issues and PRs related to the tls subsystem. semver-minor PRs that contain new features and should be released in the next minor version. labels Jan 30, 2019

addaleax approved these changes Jan 30, 2019

View reviewed changes

addaleax added lts-watch-v8.x labels Jan 30, 2019

indutny approved these changes Jan 30, 2019

View reviewed changes

vsemozhetbyt reviewed Feb 1, 2019

View reviewed changes

doc/api/tls.md Outdated Show resolved Hide resolved

vsemozhetbyt added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Feb 1, 2019

sam-github force-pushed the tls-new-session-client branch from 788939b to f544aaa Compare February 1, 2019 16:22

sam-github force-pushed the tls-new-session-client branch from f544aaa to a558e25 Compare February 1, 2019 20:30

sam-github closed this Feb 2, 2019

sam-github deleted the tls-new-session-client branch February 2, 2019 03:07

targos mentioned this pull request Feb 14, 2019

v11.10.0 proposal #26098

Merged

BethGriggs added the backport-requested-v10.x label Oct 17, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

tls: introduce client 'session' event #25831

tls: introduce client 'session' event #25831

sam-github commented Jan 30, 2019 •

edited

Loading

nodejs-github-bot commented Jan 30, 2019

sam-github commented Jan 30, 2019

indutny left a comment

sam-github commented Feb 2, 2019

tls: introduce client 'session' event #25831

tls: introduce client 'session' event #25831

Conversation

sam-github commented Jan 30, 2019 • edited Loading

Checklist

nodejs-github-bot commented Jan 30, 2019

sam-github commented Jan 30, 2019

indutny left a comment

Choose a reason for hiding this comment

sam-github commented Feb 2, 2019

sam-github commented Jan 30, 2019 •

edited

Loading