@@ -321,9 +321,9 @@ in [`tls.createServer()`][], [`tls.connect()`][], and when creating new
321
321
322
322
The ciphers list can contain a mixture of TLSv1.3 cipher suite names, the ones
323
323
that start with ` 'TLS_' ` , and specifications for TLSv1.2 and below cipher
324
- suites. The TLSv1.2 ciphers support a legacy specification format, consult
324
+ suites. The TLSv1.2 ciphers support a legacy specification format, consult
325
325
the OpenSSL [ cipher list format] [ ] documentation for details, but those
326
- specifications do * not* apply to TLSv1.3 ciphers. The TLSv1.3 suites can only
326
+ specifications do * not* apply to TLSv1.3 ciphers. The TLSv1.3 suites can only
327
327
be enabled by including their full name in the cipher list. They cannot, for
328
328
example, be enabled or disabled by using the legacy TLSv1.2 ` 'EECDH' ` or
329
329
` '!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
@@ -1623,11 +1623,11 @@ changes:
1623
1623
[ OpenSSL Options] [ ] .
1624
1624
* ` secureProtocol ` {string} Legacy mechanism to select the TLS protocol
1625
1625
version to use, it does not support independent control of the minimum and
1626
- maximum version, and does not support limiting the protocol to TLSv1.3. Use
1627
- ` minVersion ` and ` maxVersion ` instead. The possible values are listed as
1628
- [ SSL_METHODS] [ ] , use the function names as strings. For example, use
1626
+ maximum version, and does not support limiting the protocol to TLSv1.3. Use
1627
+ ` minVersion ` and ` maxVersion ` instead. The possible values are listed as
1628
+ [ SSL_METHODS] [ ] , use the function names as strings. For example, use
1629
1629
` 'TLSv1_1_method' ` to force TLS version 1.1, or ` 'TLS_method' ` to allow any
1630
- TLS protocol version up to TLSv1.3. It is not recommended to use TLS
1630
+ TLS protocol version up to TLSv1.3. It is not recommended to use TLS
1631
1631
versions less than 1.2, but it may be required for interoperability.
1632
1632
** Default:** none, see ` minVersion ` .
1633
1633
* ` sessionIdContext ` {string} Opaque identifier used by servers to ensure
@@ -1825,7 +1825,7 @@ added: v11.4.0
1825
1825
[ ` tls.createSecureContext() ` ] [ ] . It can be assigned any of the supported TLS
1826
1826
protocol versions, ` 'TLSv1.3' ` , ` 'TLSv1.2' ` , ` 'TLSv1.1' ` , or ` 'TLSv1' ` .
1827
1827
** Default:** ` 'TLSv1.3' ` , unless changed using CLI options. Using
1828
- ` --tls-max-v1.2 ` sets the default to ` 'TLSv1.2' ` . Using ` --tls-max-v1.3 ` sets
1828
+ ` --tls-max-v1.2 ` sets the default to ` 'TLSv1.2' ` . Using ` --tls-max-v1.3 ` sets
1829
1829
the default to ` 'TLSv1.3' ` . If multiple of the options are provided, the
1830
1830
highest maximum is used.
1831
1831
0 commit comments