CIPHERS.md: fix the example that uses only TLS 1.3

[jay]

• Add --tls-max 1.3 to set the maximum version to TLS 1.3.

Prior to this change the example set the minimum version to TLS 1.3 but not the maximum version to TLS 1.3.

Ref: #21702

Closes #xxxxx

[vszakats]

This fixes the command on Windows Server 2019, to say:

curl: (35) schannel: TLS 1.3 not supported on Windows prior to 11

As a layman with these options, I admit I don't grok why setting
the maximum is necessary to achieve this. Considering there is no
higher TLS version than 1.3, and we already set it as minimum.

[jay]

This fixes the command on Windows Server 2019, to say:

curl: (35) schannel: TLS 1.3 not supported on Windows prior to 11

Yeah I guess some of our code does not allow TLS 1.3 in versions of Windows prior to 11 and other code does? I don't recall the reasons for that.

[vszakats]

That's what seems to be happening, out of three checks, two guard for 2022 (I forgot rev nr), and one other for rev 17763. Maybe worthy to sync up the latter?

Agree that enabling 1.3 for older versions is not the adventure for most and def not for production. (Oops meant to reply this under the refed Issue)

[jay]

That's what seems to be happening, out of three checks, two guard for 2022 (I forgot rev nr), and one other for rev 17763. Maybe worthy to sync up the latter?

@wyattoday do you remember the reasons for this, schannel_set_ssl_version_min_max doesn't use TLS 1.3 on versions older than Windows 11 but the schannel acquire_sspi_handle specifically allows it for earlier versions. Was that an oversight or intentional?

[wyattoday]

@jay Intentional. Windows 10 had a broken TLS 1.3 implementation. It was explicitly excluded for that reason. Have they since created a parallel working Windows 10 build that inherits the Windows 11 TLS stack? I doubt it, but I don't know. MSDN documentation doesn't say anything about it ... and MSDN is quickly turning into a AI-slop pile.

And the one or 2 Microsoft TLS devs that are active on github have been unable / unwilling to contribute (see my past PRs asking them to fill in the many gaping holes in their public documentation).

@vszakats

That's what seems to be happening, out of three checks, two guard for 2022 (I forgot rev nr), and one other for rev 17763. Maybe worthy to sync up the latter?

This was a deliberate choice for Windows 10 that supported the newer API to use it. But there's honestly no reason to make that distinction anymore. Might as well exclude the Windows 10 users from the newer API. That way it will simplify bug detection in the future (Windows 10 an older get old API, Windows 11 and newer get new API + TLS 1.3).

[jay]

Ok thanks I think it's worth considering.

[vszakats]

This recent-looking MSDN page: https://learn.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-
says 1.3 is unsupported below 2022/11.

(If any amount of 1.3 support is present in earlier releases, it seems to have stuck in experimental/unsupported/disabled-by-default state. I also could not find official documentation on how to enable it. Maybe it was meant as an insider feature for testing purposes?)