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.

[sambrightman]

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 don't think this aligns with the discussion in the rest of this thread - i.e. changing to 1.3 hurts some people (whose clients don't support 1.3 - like #3120) without benefitting others who get auto-upgraded when 1.2 is specified. The latter two PRs seem to have reached a similar conclusion. I think the first should be reverted, right?

[sanmai-NL]

Supporting TLS 1.2 harms the persons paying for hosting due to lesser performance, and the user in their security (integrity of executable downloaded). Accepting TLS 1.2 as minimum in the user instructions entails that should the client use Internet under the control of an oppressive entity, they are then more at risk than they were before. It's a choice you may make, but given that the user issue has popped up only now, many years after TLS 1.3. support was added to curl, suggests it is an anomaly and that it is best resolved by those few users themselves.

[sambrightman]

The current consensus within these issues is clearly not to break such users, including but not limited to reasoning about LTS releases. You previously said the 1.2 flag was good already due to the protocol auto-upgrading. I think nobody whose client supports 1.3 is adding server costs or compromising their security? Did you change your mind?

If so, it might be good to argue that case in the latter two tickets so that things are consistent. I don’t see the upside of that approach myself.