Hi, Please forgive me if this is not the correct place to make this posting and let me know the correct place instead.
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? There are several areas of concern and possible remediation needed. 1. Scope of impact. The proposal itself mentions insufficient metrics to understand current usage of TLS RSA KEX in the wild and discussion was limited to Internet clients and servers. Such usage in fact includes: - Embedded web servers - Server out of band remote management (iLOMs etc) - Older web acceleration / proxy servers - Other protocol proxy servers (LDAP, IMAP etc) - Golang monitoring systems monitoring older type of servers Most of the above usage will not appear in Internet cipher suite usage statistics. 2. Documentation. There is insufficient documentation around this high impact change. Existing documentation is limited to: - A small mention in release notes - The proposal itself - A couple of support tickets There is no documentation or workarounds written up or referenced to support non programmers impacted by this change. This is a behavioural change in Golang, so relying on vendor / OSS documentation to percolate through is insufficient. Often such projects are only discovering issues at the same time as end users. The significance of the one line release note statement is easy to miss. 3. Impact of change. The change completely breaks client server connectivity where TLS RSA KEX is the only supported cipher suite. The high impact coupled with lack of documentation, especially aimed at non programmers (think System/Network/DevOps administrators), is causing undesirable behaviours and poor security posture as the people balance the breakage against other competing goals. Some outcomes observed include: - Revert communications to clear text (really not a desirable outcome but it has happened) - Bypass the broken system - Revert to older implementation and mark system / application as high risk for upgrade. (Effectively blocking all changes) This is not a good security outcome. Even reasonable encryption is better than no encryption and lots of encryption implementations do not guarantee PFS which was one of the two major motivations behind this proposal change. 4. Ongoing support of legacy cipher suites. There needs to be some guarantees made for: - Keeping GODEBUG=tlsrsakex=1 for a certain time period to allow vendors, implementations and impacted communities to move forward. I would expect several years, like 5 or more, may be in order. - Keeping older and deprecated cipher suites available for legacy applications accessibility. As it stands, I am not aware of current policies where something hidden behind GODEBUG is maintained for any set length of time. There is a risk here of the tlsrsakex=1 workaround breaking in future (even tomorrow) and requiring yet further interventions or removal of Golang applications. The systems impacted are often older, lower powered, potentially out of support and remain needing access at the highest security standard that existed at their time of implementation. Looking to vendor's / OSS for updates to said systems in such ecosystems is a very long process. 5. Improvements to the Proposal methodology. This is an interesting case, as reading through Golang's documentation around proposals has lots of info about the process of proposal being accepted and implemented, but very little to nothing about post proposal acceptance and implementation ongoing review. The procedure basically stops at the it is implemented, released and done stage. Whereas the lifecycle of the proposal is in fact only just starting as the proposal's implementation is now introduced into the wild. Maybe these issues could be a good candidate case for sparking discussions on improving proposal considerations and post implementation review. Regards, 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/97106c1f-efdc-4eeb-9eea-19325999f503n%40googlegroups.com.
