Investigate and implement support for TLS1.3 in `rustup-init.sh`

[kinnison]

Whatever fronts https://rustup.rs now supports TLS1.3 - we should look into what it'd take to detect support in the system curl or wget binaries in order to adjust rustup-init.sh to support TLS1.3

Also we should see if there's any hope we can detect the TLS version used to visit https://rustup.rs/ and offer a TLS1.3 install command to copy/paste if that's possible.

[sanmai-NL]

I think we're good to go already. We use --tlsv1.2 which means curl uses TLS v1.3 by preference, if it knows about it. As for Wget, its behavior isn't documented as such but it seems to do the same.

[kinnison]

That's still opportunistic. If we want to force 1.3 we'd need to say --tlsv1.3 surely?

[sanmai-NL]

Only if you decide that you needn't be compatible with with older clients. But that is contrary to the logic you describe in your opening post. Instead, you may want to turn this into a feature to warn users about imperfect security during their usage.

[BryanQuigley]

Pretty sure all modern browsers will use TLS1.3, so detecting that their browser supports it won't be very predictive - although I see in OS detection is already done for some.

Curl's changelog indicates tls1.3 was added in 7.52.0 - December 21 2016.

A quick pkgs search indicates that a lot would be fine. Highlighting the major ones (IMHO) that would not support tls1.3:
CentOS 6/7 (without backports), Ubuntu 14.04 ESM/16.04. Slackware 14.1/14.2 (really old?)

Both Cent/RHEL 6 and Ubuntu 14.04 are both in some sort of enterprisey life support mode. Ubuntu 16.04 goes enterprisey life support mode in April 2021. CentOS 7 in 2024.

[kinnison]

Sounds like @sanmai-NL is right then, perhaps we just accept that we'll opportunistically upgrade to 1.3 on almost every platform and not worry too much about the few left that @BryanQuigley identified?

[BryanQuigley]

Cloudflare let's me see different tls version in usage - does Cloudfront?
Also opened a related #2582 - it seems Cent OS 6 also might not handle tls1.1/1.2 properly under some scenarios.

[pothos]

The change was done now for the initial curl command that downloads the script: rust-lang/book#3130
I've filed two similar PRs here: #2996 and rust-lang/www.rust-lang.org#1670

I didn't touch the script itself, though, because it's easier for users to fix the curl argument in the copy-pasted command line if they experience incompatibilities and report the problem before we switch the script logic and introduce a problem deep inside it which users can't work around easily.

[pothos]

As pointed out again in rust-lang/www.rust-lang.org#1670, the curl TLS 1.2 flag already uses 1.3 if possible. I think it's ok to leave it like that unless TLS 1.2 is broken for the use case at hand which is limited to authentication of the content.

[sanmai-NL]

@kinnison Given how this thread concluded, I think it can be closed.