Go tls.Config.CurvePreferences 怎样控制椭圆曲线选择

如果 Go 程序在升级后出现 TLS 握手兼容性变化，先看 tls.Config.CurvePreferences 是否被显式填过。这个字段控制的是“允许参与密钥交换的集合”，不是按照切片从前到后强制选择某条椭圆曲线。留空时使用 Go 当前版本的默认集合；一旦写入非空切片，就由应用接管这份允许列表。

官方文档：https://pkg.go.dev/crypto/tls#Config

本文以迁移视角整理最小写法、Go 1.24 和 Go 1.26 的默认变化，以及怎样从 ConnectionState.CurveID 读取最终协商结果。

先把 CurvePreferences 的语义说清楚

CurvePreferences 的类型是 []tls.CurveID，名称中的“Curve”是历史称呼。今天它表达的是 TLS 密钥交换机制集合，里面既可以有传统组，也可以有混合后量子密钥交换组。

最容易误读的地方是切片顺序。官方文档明确说明，列表顺序会被忽略，实际机制从列表中选择时仍使用内部偏好顺序。因此下面的两种写法表达的是两个不同的允许集合，但不能把第一项理解成“优先强制使用”。

package main

import "crypto/tls"

func configs() (*tls.Config, *tls.Config) {
	// 空切片表示交给当前 Go 版本的默认密钥交换集合。
	useDefault := &tls.Config{}

	// 非空切片表示应用明确收紧允许集合；顺序不是优先级。
	compatibility := &tls.Config{
		CurvePreferences: []tls.CurveID{
			tls.X25519,
			tls.CurveP256,
			tls.CurveP384,
		},
	}
	return useDefault, compatibility
}

如果你的目标只是“使用 Go 默认能力”，不要为了看起来完整而复制一份旧的曲线列表。显式列表会冻结允许范围，未来 Go 新增默认机制时也不会自动进入这份列表。

升级前后要重点对照哪些变化

迁移检查可以先看三件事：配置是否为空、列表里是否只保留传统组、程序是否把最终协商结果记录出来。Go 官方文档当前给出了明确的默认变化：

这里的“包含”只描述默认集合，不表示每次握手都会选择这些机制。最终结果还取决于客户端、服务端和当前 TLS 参数是否存在共同支持项。

旧代码为什么会在升级后失去默认能力

许多旧配置会把 CurveP256、CurveP384 和 X25519 写成一个固定切片，原因通常是对端设备较旧，或项目曾经需要限定兼容范围。这样的代码并不一定错误，但它已经从“使用默认集合”变成了“只允许这三组”。

func legacyTLSConfig() *tls.Config {
	return &tls.Config{
		// 这是一份明确的兼容白名单，不会随 Go 默认集合自动扩展。
		CurvePreferences: []tls.CurveID{
			tls.CurveP256,
			tls.CurveP384,
			tls.X25519,
		},
	}
}

迁移时不要简单地把更多常量追加到列表末尾，也不要把切片排序当成协商优先级。先回答业务问题：需要保持哪些旧对端？是否允许新的混合后量子密钥交换？是否必须在不同 Go 版本上得到同一组可观测结果？答案不同，配置策略也不同。

兼容性优先时怎样写显式列表

如果确实需要固定集合，可以把列表集中在一个构造函数中，并在旁边说明为什么保留这些组。客户端和服务端都可以使用同一个配置构造思路，但不要把“客户端配置”和“服务端配置”混为一谈：证书、最低 TLS 版本、客户端认证等字段仍需要按角色分别设置。

package tlsconfig

import "crypto/tls"

func CompatibilityConfig() *tls.Config {
	return &tls.Config{
		MinVersion: tls.VersionTLS12,
		// 只保留经过对端矩阵确认的组；列表顺序不代表优先级。
		CurvePreferences: []tls.CurveID{
			tls.X25519,
			tls.CurveP256,
			tls.CurveP384,
		},
	}
}

这种写法的价值是可审阅、可回滚。它的代价也必须写在迁移记录中：显式列表不会自动吸收 Go 新版本新增的默认项。若项目最终决定跟随默认集合，就应删除这段白名单，而不是维护一份越来越长的复制品。

怎样判断配置是否真的参与了握手

不要从配置切片本身推断最终结果。握手成功后，可以从连接状态读取 CurveID；它表示本次连接使用的密钥交换机制。下面的辅助函数只负责读取状态并输出稳定的观察信息，错误仍由调用方处理。

package main

import (
	"crypto/tls"
	"fmt"
)

func reportConnection(conn *tls.Conn) error {
	if err := conn.Handshake(); err != nil {
		// 握手失败先返回原始错误，不把它误判成曲线配置问题。
		return fmt.Errorf("TLS 握手失败: %w", err)
	}

	state := conn.ConnectionState()
	// CurveID 是本次连接的结果，不是 CurvePreferences 的列表顺序。
	fmt.Printf("TLS=%s, CurveID=%s, ALPN=%s\n",
		tls.VersionName(state.Version), state.CurveID, state.NegotiatedProtocol)
	return nil
}

如果握手失败，先根据错误区分“没有共同支持的密钥交换组”和证书、协议版本、SNI 等其它问题。只有连接成功后，ConnectionState.CurveID 才能回答“本次最终用了什么”。不要把静态说明图或日志示例当成某个真实对端的实测证据。

把版本迁移检查放进回归清单

升级 Go 或调整 TLS 策略时，可以按下面顺序审阅：

1. 搜索所有 CurvePreferences 初始化点，区分空配置和非空配置。
2. 记录显式列表的业务原因，确认每个组仍有对应的对端或合规要求。
3. 对照当前 Go 文档，确认默认集合新增的机制是否应被允许。
4. 在兼容性矩阵中覆盖旧设备、现代客户端和服务端两种角色。
5. 将握手错误与 ConnectionState.CurveID 作为可观察结果记录，不只记录“连接成功”。
6. 保留旧配置的回滚开关，但不要在没有证据时盲目扩大或收紧白名单。

常见误区和边界

把切片第一项当成强制优先项

这是最常见的误读。官方语义是列表顺序被忽略，内部偏好顺序仍由 Go 处理。想知道实际结果，应读取连接状态，而不是重排切片后猜测。

以为显式列表只是“补充默认项”

非空列表是应用自己的支持集合。它不是在默认集合上追加，也不是未来默认值的别名。需要默认行为时，让字段保持为空通常更直接。

把所有握手失败都归因于 CurvePreferences

证书验证、TLS 版本、SNI、ALPN、客户端认证和网络中断都可能导致握手失败。曲线配置只是其中一个维度，必须结合原始错误和连接两端的配置判断。

结语：先决定是否接管默认值

CurvePreferences 的核心不是“如何排列椭圆曲线”，而是“应用是否要接管 Go 的默认密钥交换集合”。留空代表跟随当前版本默认值；非空代表明确限制允许集合，且列表顺序不提供强制优先级。Go 1.24 和 Go 1.26 的默认变化提醒我们：升级时最值得检查的不是常量名字，而是旧白名单是否仍然表达真实的兼容性目标。

如果你只需要一个稳妥的迁移动作，先找出显式列表，再用兼容性矩阵和 ConnectionState.CurveID 判断它是否仍然必要。确认不需要固定集合后，删除冗余白名单，让默认策略承担后续演进。

相关问题

CurvePreferences 的顺序能决定优先使用 X25519 吗？

不能。列表顺序会被忽略，实际选择使用内部偏好顺序；要观察结果请读取连接状态。

显式配置后还能使用 Go 新版本新增的混合组吗？

只有当这些机制明确出现在你的列表中并且对端也支持时才可能参与协商。否则显式列表会把它们排除在外。

怎样确认本次连接用了哪种组？

握手成功后读取 conn.ConnectionState().CurveID，并把它与握手错误、TLS 版本等信息一起记录。