crypto/tls
ConnectionState.ExportKeyingMaterial will now return an error unless TLS 1.3 is in use, or the extended_master_secret extension is supported by both the server and client. crypto/tls has supported this extension since Go 1.20. This can be disabled with the tlsunsafeekm=1 GODEBUG setting.
By default, the minimum version offered by crypto/tls servers is now TLS 1.2 if not specified with config.MinimumVersion, matching the behavior of crypto/tls clients. This change can be reverted with the tls10server=1 GODEBUG setting.
By default, cipher suites without ECDHE support are no longer offered by either clients or servers during pre-TLS 1.3 handshakes. This change can be reverted with the tlsrsakex=1 GODEBUG setting.
However, the default go1.22 binaries are built with go1.21 (most distros, and the golang official binaries), and it means they all gain by default build DefaultGODEBUG=httplaxcontentlength=1,httpmuxgo121=1,tls10server=1,tlsrsakex=1,tlsunsafeekm=1 upon inspecting the binaries built with go1.22 toolchain.
Meaning, that all of these hardened behaviour is actually not enabled for anybody using 1.22 toolchains, contrary to the release notes.
Is it intentional that behaviour changes “since 1.2N” are actually enabled by default in “1.2(N+1)”?
When a GODEBUG setting is not listed in the environment variable, its value is derived from three sources: the defaults for the Go toolchain used to build the program, amended to match the Go version listed in go.mod, and then overridden by explicit //go:debug lines in the program.
so none of the programmes use 1.22 defaults, because they list go 1.21 in their go.mod. Diddums. It seems like I may need to set explicit GODEBUG to make things work how I want when building them.
It’s likely that future versions of Go (beyond 1.22) will have the security hardening changes enabled by default in the pre-built binaries. This will eventually enforce the stricter TLS requirements described in the Go 1.22 release notes.