crypto/tls: make default minimum version for servers TLS 1.2

[rolandshoemaker]

Resurrecting stage 2 of #45428, in light of Microsoft recently disabling support for 1.0 and 1.1 by default in Windows (see https://techcommunity.microsoft.com/t5/windows-it-pro-blog/tls-1-0-and-tls-1-1-soon-to-be-disabled-in-windows/ba-p/3887947).

Since #45428 was written SSL Pulse now shows that only <0.1% of surveyed servers only support TLS 1.1 or lower. Given the typically extremely cautious Microsoft seems happy to disable client support for 1.0 and 1.1 by default, it is perhaps reasonable to assume that the number of servers that actually require clients which support these version is rather miniscule.

Note the number of clients which still only support 1.0 or 1.1 is still non-zero though, and this proposal does not propose to completely remove support for these versions, simply not enable it by default. People who still want to support clients which only support 1.0 or 1.1 can still enable this support by setting the Config.MinimumVersion field.

Following the plan suggested in #45428, I propose we pre-announce that we will be changing the default Config.MinimumVersion for servers in 1.22, and in 1.23 we make the change.

cc @FiloSottile @golang/security

[FiloSottile]

Generally speaking, I can't wait to turn off TLS 1.0 and 1.1.

However I want to point out that stage 2 of #45428 is about turning them off by default server side, so what matters are

1. numbers on how many clients only support TLS 1.0 and 1.1 and would break; and
2. examples of other servers that turned off TLS 1.0 and 1.1 support by default.

The Microsoft change is both client-side and server-side, but most Schannel users are client-side, and I can't figure out if it applies to e.g. IIS.

From SSL Pulse, the relevant number is not 0.1% servers supporting at most TLS 1.0 (that was relevant to turning off client-side support), but that 32.5% of sites still support TLS 1.1.

Is there anywhere we can get numbers on how many clients still negotiate TLS 1.0 or 1.1? Maybe Cloudflare?

[rolandshoemaker]

The Microsoft change is both client-side and server-side, but most Schannel users are client-side, and I can't figure out if it applies to e.g. IIS.

I cannot find a specific reference now, but my memory from when I first looked into this was that it was implied this also affect all Microsoft server software shipped with Windows, as well as clients.

Is there anywhere we can get numbers on how many clients still negotiate TLS 1.0 or 1.1? Maybe Cloudflare?

Cloudflare data (assuming that the total includes TLS 1.0 and TLS 1.1 connections, but aren't separated out on the graph) shows ~0.3% 1.0 and 1.1 connections. Internal Google metrics show a similar (ever so slightly lower) number for 1.0 and 1.1.

Given how small a population this appears to be, seems reasonable to disable by default.

[FiloSottile]

Cloudflare data (assuming that the total includes TLS 1.0 and TLS 1.1 connections, but aren't separated out on the graph) shows ~0.3% 1.0 and 1.1 connections. Internal Google metrics show a similar (ever so slightly lower) number for 1.0 and 1.1.

~0.3% is very reassuring, let's do it.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[FiloSottile]

According to the SSLLabs client handshakes library, these are the latest major clients that don't support TLS 1.2.

• Android 4.3
• Chrome 29 on Win 7
• Firefox 26 on Win 8
• IE 8 on Win XP
• IE 8-10 Win 7
• IE 10 Win Phone 8.0
• Java 7u25
• OpenSSL 0.9.8y
• Safari 6.0.4 on OS X 10.8.4

"Can I use" agrees. https://caniuse.com/tls1-2

They all seem ancient enough. (Time flies!) I think I'd be comfortable doing this (with a godebug) in Go 1.22, along with #63413, without the pre-announcement cycle. I have no evidence or feedback that those pre-announcements ever helped, and in this case in particular I think anyone who knows they need TLS 1.0 would have already set MinVersion, so they won't be alerted to anything useful by it.

[rolandshoemaker]

Agreed on the accelerated timeline, I don't see any particularly significant benefit from delaying this (at this point already somewhat overdue) security win.

[rsc]

I agree that having the GODEBUG should mean that we can skip the preannouncement.

[rsc]

Sounds like the proposal is:

In servers that do not set Config.MinimumVersion, require TLS 1.2 now, instead of the current TLS 1.1. A new GODEBUG tls11server=1 will re-enable TLS 1.1. Only main modules with “go 1.22” or newer in the go.mod will default to tls11server=0 (TLS 1.1 disabled). Older versions will continue to default to tls11server=1, with no change in behavior other than the new metrics counter recording their TLS 1.1 usage.

Do I have that right? In particular, I am assuming it is feasible in the TLS proposal to IncNonDefault only when a client chooses TLS 1.1, not just when the server offers it?

[FiloSottile]

Yes, except it’s TLS 1.0, not TLS 1.1. (The latter is very similar to the former and rarely supported without also supporting TLS 1.2.)

[rsc]

Hmm. The fact that we're removing TLS 1.0 and 1.1 makes this a bit awkward for picking a GODEBUG name.
Should it be tls12server=1 (require 1.2) for the new behavior and tls12server=0 (do not require 1.2) for the old behavior?

[FiloSottile]

I think TLS 1.1 is so insignificant that we can call it tls10server.

[rsc]

OK, so tls10server=1 will enable TLS 1.0/1.1, and tls10server=0 (the new default in a future Go release) will disable it.

[mateusz834]

Will Config.MinVersion = tls.VersionTLS10 still work? Edit: it will

I also wonder whether it would be better to make the GODEBUG differently, like tlsserverminversion=2, then in future it would be easier to make tls 1.3 the default min version. If we do it the tls10server=1 way, then it some future point there might be a need to add tls12server=1. With the tlsserverminversion, it will only require to bump the number without any new GODEBUG. What do you think?

[FiloSottile]

Not letting GODEBUGs proliferate is appealing, especially as they start interacting in the future, but I still lean towards tls10server=1 because who knows if we will switch off TLS 1.2 for client and server separately, who knows how long from now that will be, and the value of tlsserverminversion is harder to understand. (Is 2 TLS 1.2, or step 2? Does 1 work? Does 3 already work?)

[rsc]

I agree with @FiloSottile. go.dev/doc/godebug talks about retiring entire GODEBUG keys, not just specific values, and the metrics about non-default behavior are also gathered per-key, not per-value.

[rsc]

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group

In servers that do not set Config.MinimumVersion, require TLS 1.2 now, instead of the current TLS 1.0/1.1. A new GODEBUG tls10server=1 will re-enable TLS 1.0/1.1. Only main modules with “go 1.22” or newer in the go.mod will default to tls10server=0 (TLS 1.0/1.1 disabled). Older versions will continue to default to tls10server=1, with no change in behavior other than the new metrics counter recording their TLS 1.0/1.1 usage.

[rsc]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

In servers that do not set Config.MinimumVersion, require TLS 1.2 now, instead of the current TLS 1.0/1.1. A new GODEBUG tls10server=1 will re-enable TLS 1.0/1.1. Only main modules with “go 1.22” or newer in the go.mod will default to tls10server=0 (TLS 1.0/1.1 disabled). Older versions will continue to default to tls10server=1, with no change in behavior other than the new metrics counter recording their TLS 1.0/1.1 usage.

[gopherbot]

Change https://go.dev/cl/541516 mentions this issue: crypto/tls: change default minimum version to 1.2