@@ -325,9 +325,9 @@ in [`tls.createServer()`][], [`tls.connect()`][], and when creating new
325
325
326
326
The ciphers list can contain a mixture of TLSv1.3 cipher suite names, the ones
327
327
that start with ` 'TLS_' ` , and specifications for TLSv1.2 and below cipher
328
- suites. The TLSv1.2 ciphers support a legacy specification format, consult
328
+ suites. The TLSv1.2 ciphers support a legacy specification format, consult
329
329
the OpenSSL [ cipher list format] [ ] documentation for details, but those
330
- specifications do * not* apply to TLSv1.3 ciphers. The TLSv1.3 suites can only
330
+ specifications do * not* apply to TLSv1.3 ciphers. The TLSv1.3 suites can only
331
331
be enabled by including their full name in the cipher list. They cannot, for
332
332
example, be enabled or disabled by using the legacy TLSv1.2 ` 'EECDH' ` or
333
333
` '!EECDH' ` specification.
@@ -768,12 +768,12 @@ On the client, the `session` can be provided to the `session` option of
768
768
See [ Session Resumption] [ ] for more information.
769
769
770
770
For TLSv1.2 and below, [ ` tls.TLSSocket.getSession() ` ] [ ] can be called once
771
- the handshake is complete. For TLSv1.3, only ticket-based resumption is allowed
771
+ the handshake is complete. For TLSv1.3, only ticket-based resumption is allowed
772
772
by the protocol, multiple tickets are sent, and the tickets aren't sent until
773
773
after the handshake completes. So it is necessary to wait for the
774
- ` 'session' ` event to get a resumable session. Applications
774
+ ` 'session' ` event to get a resumable session. Applications
775
775
should use the ` 'session' ` event instead of ` getSession() ` to ensure
776
- they will work for all TLS versions. Applications that only expect to
776
+ they will work for all TLS versions. Applications that only expect to
777
777
get or use one session should listen for this event only once:
778
778
779
779
``` js
@@ -1610,11 +1610,11 @@ changes:
1610
1610
[ OpenSSL Options] [ ] .
1611
1611
* ` secureProtocol ` {string} Legacy mechanism to select the TLS protocol
1612
1612
version to use, it does not support independent control of the minimum and
1613
- maximum version, and does not support limiting the protocol to TLSv1.3. Use
1614
- ` minVersion ` and ` maxVersion ` instead. The possible values are listed as
1615
- [ SSL_METHODS] [ ] , use the function names as strings. For example, use
1613
+ maximum version, and does not support limiting the protocol to TLSv1.3. Use
1614
+ ` minVersion ` and ` maxVersion ` instead. The possible values are listed as
1615
+ [ SSL_METHODS] [ ] , use the function names as strings. For example, use
1616
1616
` 'TLSv1_1_method' ` to force TLS version 1.1, or ` 'TLS_method' ` to allow any
1617
- TLS protocol version up to TLSv1.3. It is not recommended to use TLS
1617
+ TLS protocol version up to TLSv1.3. It is not recommended to use TLS
1618
1618
versions less than 1.2, but it may be required for interoperability.
1619
1619
** Default:** none, see ` minVersion ` .
1620
1620
* ` sessionIdContext ` {string} Opaque identifier used by servers to ensure
@@ -1812,7 +1812,7 @@ added: v11.4.0
1812
1812
[ ` tls.createSecureContext() ` ] [ ] . It can be assigned any of the supported TLS
1813
1813
protocol versions, ` 'TLSv1.3' ` , ` 'TLSv1.2' ` , ` 'TLSv1.1' ` , or ` 'TLSv1' ` .
1814
1814
** Default:** ` 'TLSv1.3' ` , unless changed using CLI options. Using
1815
- ` --tls-max-v1.2 ` sets the default to ` 'TLSv1.2' ` . Using ` --tls-max-v1.3 ` sets
1815
+ ` --tls-max-v1.2 ` sets the default to ` 'TLSv1.2' ` . Using ` --tls-max-v1.3 ` sets
1816
1816
the default to ` 'TLSv1.3' ` . If multiple of the options are provided, the
1817
1817
highest maximum is used.
1818
1818
0 commit comments