Stage 3 seems like a copy-paste typo. If the protocols have been removed (code yeeted), then I don’t see how they could possibly be re-enabled
at run-time.

Stage 3 seems like a copy-paste typo. If the protocols have been removed (code yeeted), then I don’t see how they could possibly be re-enabled at run-time.

The code will be yeeted at TBD+2, in TBD+1 it will behave as if it was removed unless GODEBUG is set. The difference is that Config.MinVersion will stop working.

Stage 3 seems like a copy-paste typo. If the protocols have been removed (code yeeted), then I don’t see how they could possibly be re-enabled at run-time.

The code will be yeeted at TBD+2, in TBD+1 it will behave as if it was removed unless GODEBUG is set. The difference is that Config.MinVersion will stop working.

Ah I see, I see. That makes sense. It might help to clarify that in “This can be temporarily overridden with both Config.MinVersion and a GODEBUG value.” because that seems to state they’d both keep working during the transition.

Retitled to be clear this proposal discussion and potential approval is only for "Stage 1".

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

I'd like to oppose this proposal - both its first stage and in its entirety. With the caveat that I would be OK to replace the code I use with an extended library version of the packages (golang.org/x).

The data you put forward assumes publicly visible servers. In private networking the mentality that says "if it is not broken, don't fix it" creates a dramatically different reality. The fact is that I still need to interface with a lot of software with broken crypto (SSLv3, TLS1.0 etc).

The introduction and adoption of this proposal would create me a very big problem - in order to keep interfacing with old software, I would have to keep my own go installation frozen in time, or bear the cost of keeping a fork.

Please, reconsider this proposal - either don't proceed with it, or offer an extended library that I could keep using.

Thanks @FiloSottile @rsc

The fact is that I still need to interface with a lot of software with broken crypto (SSLv3, TLS1.0 etc).

If you need SSLv3 I assume you are already using a fork?

Since this is a proposal for approval of Stage 1, are you saying you need to connect to servers which don't support TLS 1.2? That would imply no modern browsers can connect to them either, so could you share what kind of software that is? How does that software get security updates? What timeline would you estimate for that software to get TLS 1.2 support?

If you need SSLv3 I assume you are already using a fork?

Or in my case, I have at least some deployments running an old version of the code. So these customers are stuck with older versions.

Since this is a proposal for approval of Stage 1, are you saying you need to connect to servers which don't support TLS 1.2?

Correct

That would imply no modern browsers can connect to them either, so could you share what kind of software that is?

Database Protocols Software and ancient deployments of remote desktop sharing software.

How does that software get security updates? What timeline would you estimate for that software to get TLS 1.2 support?

I don't believe they do. And the timeline is none. Because, "if it is not broken, don't fix it". Sad, I know.

How does that software get security updates? What timeline would you estimate for that software to get TLS 1.2 support?

I don't believe they do. And the timeline is none. Because, "if it is not broken, don't fix it". Sad, I know.

I feel for who has to maintain those systems, but making modern well-run systems pay (because remember that complexity has a security cost, in more ways than one) for systems that decided to be permanently insecure is not an option, sorry.

Anyway, it sounds like you wouldn't be affected by this change until Stage 3. Do you have any objections to Stage 1? Why?

Presumably, systems insisting on sticking to deprecated versions of TLS could also just stay on an older version of Go? I get that upgrading Go has other benefits, but I'm fully with @FiloSottile that keeping that use case working for a long time seems like the wrong tradeoff.

Do you have any objections to Stage 1? Why?

It depends on how the Stage 1 shows ups. If it is a parameter (Config.MinVersion override), then it is fine. Adjusting the behavior through env vars (like GODEBUG) is a way harder sell - I'd have to either ask my customers to deploy a configuration change (tough sell - "it is working, why do you want me to change it?").

I feel for who has to maintain those systems, but making modern well-run systems pay (because remember that complexity has a security cost, in more ways than one) for systems that decided to be permanently insecure is not an option, sorry.

I agree with you, and that's why I suggested keeping the deprecated software under golang.org/x. But perhaps it doesn't make sense? I defer to you.

systems insisting on sticking to deprecated versions of TLS could also just stay on an older version of Go?

I tried it - it works well. As long as my dependencies decide their minimum go versions is as old or older than the old Go version I'd need to keep around, plus manually back-porting other Go changes (non-crypto changes) into the old Go version. If possible, I'd like to avoid this situation.

Do you have any objections to Stage 1? Why?

It depends on how the Stage 1 shows ups. If it is a parameter (Config.MinVersion override), then it is fine. Adjusting the behavior through env vars (like GODEBUG) is a way harder sell - I'd have to either ask my customers to deploy a configuration change (tough sell - "it is working, why do you want me to change it?").

Stage 1 and 2 just change the default MinVersion value. GODEBUG is never a long term setting, it's just a way to easily triage a failure by setting something in the environment without going around rebuilding everything involved.

Edit: clarified in the proposal that Stage 1 and 2 effectively change the default Config.MinVersion.

I feel for who has to maintain those systems, but making modern well-run systems pay (because remember that complexity has a security cost, in more ways than one) for systems that decided to be permanently insecure is not an option, sorry.

I agree with you, and that's why I suggested keeping the deprecated software under golang.org/x. But perhaps it doesn't make sense? I defer to you.

Unfortunately the TLS stack is not easy to swap in and out: #21753. It would be nice to make it easier and is something we keep in mind as we plan larger changes. In general, we also can't maintain forks for everyone's custom requirements, so it would have to be a community project.

Unfortunately the TLS stack is not easy to swap in and out: #21753. It would be nice to make it easier and is something we keep in mind as we plan larger changes. In general, we also can't maintain forks for everyone's custom requirements, so it would have to be a community project.

In any case, thanks for caring @FiloSottile

I know that many users are using 512m memory servers to run their software, XP win 2003, win7 systems, WINAPI does not support TLS1.2 (win7 can be supported by an update patch), so some server also needs to retain TLS1.2.
So I am not opposed to modifying Config.MinVersion, but I think the old version of TLS code should be retained and can be enabled, otherwise some service providers can only use the old version of golang on the server for customers, which will bring greater risks and a lot of inconvenience.

I know that many users are using 512m memory servers to run their software, XP win 2003, win7 systems, WINAPI does not support TLS1.2 (win7 can be supported by an update patch), so some server also needs to retain TLS1.2.
So I am not opposed to modifying Config.MinVersion, but I think the old version of TLS code should be retained and can be enabled, otherwise some service providers can only use the old version of golang on the server for customers, which will bring greater risks and a lot of inconvenience.

Let's say a programmer who doesn't know about this flaw implements this into their code, and they work for a bank and makes it into production, than they are screwed, I say we remove it from the standard package and maybe add it to another package. (non-standard one) and if they really want to use it they still have the option to import it from another package.

I know that many users are using 512m memory servers to run their software, XP win 2003, win7 systems, WINAPI does not support TLS1.2 (win7 can be supported by an update patch), so some server also needs to retain TLS1.2.
So I am not opposed to modifying Config.MinVersion, but I think the old version of TLS code should be retained and can be enabled, otherwise some service providers can only use the old version of golang on the server for customers, which will bring greater risks and a lot of inconvenience.

Let's say a programmer who doesn't know about this flaw implements this into their code, and they work for a bank and makes it into production, than they are screwed, I say we remove it from the standard package and maybe add it to another package. (non-standard one) and if they really want to use it they still have the option to import it from another package.

Yeah, as long as there is an easy way to enable it. In fact, Config.MinVersion is a reminder, and we can even raise a warning when MinVersion<=TLS1.2.
Regarding moving out of the standard library, it seems difficult.

Unfortunately the TLS stack is not easy to swap in and out: #21753. It would be nice to make it easier and is something we keep in mind as we plan larger changes. In general, we also can't maintain forks for everyone's custom requirements, so it would have to be a community project.

#45428 (comment)

Again, this issue is about disabling support for connecting to ancient servers.
Serving (talking to) an ancient client is not affected by this issue.

It sounds like a few people are concerned about disabling by default but are OK with setting Config.MinVersion to opt out.
They would be less happy with GODEBUG, but it's fine to have as well for debugging purposes.

Do I have that right?

It sounds like a few people are concerned about disabling by default but are OK with setting Config.MinVersion to opt out.
They would be less happy with GODEBUG, but it's fine to have as well for debugging purposes.

Do I have that right?

Yes. I can live with Config.MinVersion changes. GODEBUG would create actual problems that are way harder to solve (and probably involves func init() + os.Setenv() hacks to inject changes to GODEBUG).

Change https://golang.org/cl/359779 mentions this issue: crypto/tls: set default minimum client version to TLS 1.2

@FiloSottile @golang/security This is in the 1.18 milestone. Is there something that is supposed to happen here for 1.18?

I see that in the 1.17 release notes we said "Beginning in the next release, Go 1.18, the Config.MinVersion for crypto/tls clients will default to TLS 1.2, disabling TLS 1.0 and TLS 1.1 by default. Applications will be able to override the change by explicitly setting Config.MinVersion. This will not affect crypto/tls servers."

Did that happen?

Thanks.

Change https://golang.org/cl/382454 mentions this issue: doc/go1.18: add crypto/tls, crypto/x509, and crypto/elliptic release notes

All the work is done, I just mailed the release note, bumping to Go 1.19 to remove the GODEBUG flag.

@FiloSottile is there anything to be done for Go 1.19? Checking in as this is a release blocker. Thanks.

Yeah, we just need to remove the GODEBUG flag. I'll send a CL in the next week.

Change https://go.dev/cl/400974 mentions this issue: crypto/tls: remove tls10default GODEBUG flag

Should this issue be closed? Is there anything else to do here for Go 1.19?

So just for clarity, the plan to remove "all TLS 1.0 and TLS 1.1 code" in stage 3 was abandoned?

No, but its time has definitely not come yet. Stage 2 has not happened yet, either. When it makes sense for them to happen there will be a new proposal.