I should also note that for programs built using the go.mod "go" directive, with a version set to a pre-1.22 value, due to GODEBUG semantics the default behavior will not have changed, since it will be automatically set to the value that enables the old behavior. On Tuesday, August 27, 2024 at 10:14:06 AM UTC-7 Roland Shoemaker wrote:
> I agree that in this case the release note we provided was likely not > informative enough. We try to walk the line of providing useful yet concise > notes about changes, but in this particular case we did not provide enough > detail specifically about how this change may cause breakage. > > In general though, I still believe this change was the correct choice. > Defaults in crypto/tls are one of the main ways we can provide security > benefit for users, and when weighing this change we looked at what would be > best for the vast majority of consumers of the library. Based on the > research we did, we expected that disabling these ciphers by default would > cause breakage, but only for a small number of users, which based on > experience reports we've seen so far is still true. > > It should also be noted that we didn't completely disable these > ciphersuites, we only removed them from the default set, explicitly > configuring them in the tls.Config enables them. For users who need to > support a large array of endpoints, defaults are likely to not be > appropriate in general, and the supported ciphersuites should be manually > configured. Looking through the issues referenced from the original > proposal, it looks like most downstream users who saw breakage here were > able to manually configure support for these older ciphersuites, fixing the > issue. > > That said, the error message returned here is not particularly useful, and > we should probably update it to point the user to which ciphersuites were > offered, and perhaps in this particular case note that using > GODEBUG=tlsrsakex=1 would fix the issue. This should be appropriate for > both developers, who can manually configure the needed suites, and users > who can set the GODEBUG until an upstream fix is available. > > Roland > > On Tuesday, August 27, 2024 at 9:24:45 AM UTC-7 Creaky wrote: > >> On Tuesday, August 27, 2024 at 11:56:44 PM UTC+10 Ian Lance Taylor wrote: >> >> On Mon, Aug 26, 2024 at 10:16 PM Robert Engels <ren...@ix.netcom.com> >> wrote: >> > >> > Hmm. Aren’t the endpoints supposed to negotiate the available >> cryptographic methods? >> > >> > So wouldn’t this affect non Go endpoints as well - which puts the >> burden back on the side trying to use the latest Go version which is >> removing some of the methods? >> > >> > Making it “if you upgrade to this version of Go you will no longer >> accept any clients expecting to use TLS” - unless you do X? >> >> Yes, that is my understanding. >> >> Ian >> >> >> Endpoints negotiate common cipher suites. Change removed cipher suites >> compatible with clients or servers supporting only a limited set of ciphers. >> >> Resulting error is a rather generic TLS handshake error message. Leaves >> the recipient with little direction to fault find on and makes finding >> unless you do X difficult. >> >> Just to clarify, it is not just Go servers, Go when acting as a client is >> similarly impacted. >> >> Creaky >> >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/93fc6acc-112b-499b-a0f9-f5b07838970cn%40googlegroups.com.
