On Mon, Aug 26, 2024 at 8:31 AM Creaky <whatexerc...@gmail.com> wrote: > > Want to discuss the impacts from the implementation of the proposal > crypto/tls: disable RSA key exchange cipher suites by default #63413 and > possible ways forward beyond go change some code (whilst it may fix the issue > in the short term, has certain drawbacks, takes time, and is impractical in > some cases). > > This proposal was introduced in Go Version 1.22 for crypto/tls and brought a > significant behavioural change impacting client server connectivity with very > little announcement. > > People are seeing TLS handshake failures causing complete failure of > connectivity and not knowing where the issue is. As tooling starts to take on > the 1.22 / 1.23 Golang changes, the impacts from this change are now bubbling > to the surface. > > I can see why the motivation behind the change is from a good place. There > are weaknesses in using TLS with RSA encrypted key exchange. However, the > change as implemented is producing poor outcomes. > > From a high level perspective, it is far better to protect communication with > possibly vulnerable encryption than being completely in the clear. However > this breakage is encouraging some people to revert to in clear connectivity > for lacking (unknowing) a better option. > > Reading through the original proposal it appears considerations of change > impact narrowly focused on Internet connected clients and servers and did not > consider the various audience groups impacted by the proposed (and now > accepted) change. > > This change is now causing one of the more costly failure types, that being > in the field failures. > > What can be done now this proposal is implemented? > > Can the proposal and its implementation be reversed? Or removed and > reintroduced with better communication?
Thanks for the detailed note. My takeaway here is that the Go team needs to provide better communication about the consequences that people will see from this kind of change, and how to better communicate those consequences and how to work around them. That is, I believe that the change is a good one for the overall ecosystem. But people can encounter this change and not know what caused it and not know the relatively simple workarounds that are available. As you know, those workarounds are described at https://go.dev/doc/godebug. People working with an executable program can set the GODEBUG variable in the environment. People developing a program from source can do that, and can also add a go:debug directive to the main package and/or a godebug setting in a go.mod or go.work file. There are no plans to remove the tlsrsakex setting. Still you're absolutely right that the average user will see some sort of failure to communicate, and will have no clear way to translate that into what they need to do to change. So the question is: how can we communicate that better? What are the right channels? Would a Go blog entry be sufficient? Also, what kinds of errors will users see in practice, and how can we get those errors to direct them to the GODEBUG setting? Thanks. Ian -- 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/CAOyqgcWTRwuFjZh_FEEAnJATS_io1VxP5c%2BS4Dv_oeshX-%2B0qA%40mail.gmail.com.
