They did remove the ability to control ordering for TLS 1.2 cipher suites, but that’s only because there’s no logical reason anyone should change it. TLS 1.3 never allowed controlling this because it is unnecessary.

When it comes to a crypto library, you really, really do not want configuration options beyond what is necessary. More configuration options is more opportunities for misconfigurations, and given the knowledge and skills required to fully understand the implications of these decisions as well as the consequences for doing it wrong, it is better to go without.

These are lessons learned from the bad old days of crypto libraries. If the cipher ordering needs to be (objectively) suboptimal in your use case, it sounds like something is broken and you should actually expect to need to vendor that.

The only reason you can even still control TLS 1.2 cipher suites is because of the fact that it might sometimes still be useful for legacy reasons to enable known-broken ciphers. There’s really no other logical reason to keep that option.

There's no reason to be condescending to someone who has real and legitimate concerns about this decision, which was apparently taken without any discussion or input from the broader security or dev community.

I could be wrong, but this overall decision to take the developer out of the loop seems to be assuming that:

1) the Go developers know the current correct, precise ordering better than anyone else. I wonder if DJB or Wietse or Schneier would always agree with all of these (and future) recommendations.

2) that perfect knowledge for this version continues to be correct into the indefinite future.

Next year, you might still be using Go 1.17 in production for various compatibility reasons, and a severe vuln is found in one of the cipher suites. (Let's say ChaCha20, as hard as it might be at this moment to believe that, or maybe heartbleed/crime/beast/etc never happened. Qualys SSL Labs' tests are constantly changing precisely because our knowledge about what is vulnerable changes.)

But, now, it is impossible for you to fix that and take the vulnerable ciphersuite out of contention, short of forking crypto/tls.

I’m not being condescending.

Anyways, if a serious exploit is found in the TLS stack, I would expect what you would want to do is update to the inevitable security release for your current stable version of Go. They do in fact do security releases, so it shouldn’t be a huge problem.

That leaves the only logical reason to need this lever as basically just one thing: you are dealing with broken software and need the cipher suite order to be suboptimal. And yes, I expect someone to need to fork the TLS stack for that, unless it’s common enough that many people would need to do that.

If my TLS stack is not updating in response to new security threats, that really poses a bigger problem to me than not having the levers to try to mitigate them on my own.

The only people who are being encouraged to fork crypto/tls are people building TLS testing tools. Nobody is suggesting that people building ordinary applications should run a forked Go TLS.