Go tls.CurveID 设置混合后量子密钥交换的配置方法与兼容边界

Go 的 tls.CurveID 名字里虽然有 Curve，但它现在表示的是 TLS 密钥交换机制标识，不只是传统椭圆曲线。想引入 X25519MLKEM768 这类混合后量子组，关键是先弄清 CurvePreferences 的支持集合，再用握手后的 ConnectionState.CurveID 确认实际结果。

官方资料：https://pkg.go.dev/crypto/tls#Config

先把 CurveID 看成密钥交换组标识

当前 crypto/tls 文档把 CurveID 定义为 TLS 标识类型。TLS 1.2 时代它主要对应椭圆曲线，TLS 1.3 以后扩展为 named group，并且可以包含混合后量子 KEM。常见值包括 CurveP256、CurveP384、X25519，以及 X25519MLKEM768、SecP256r1MLKEM768 等混合组。

因此，看到 CurveID 时要先问“握手使用哪一种密钥交换组”，不要把它和证书公钥曲线、签名算法或 CipherSuites 混为一谈。三者都可能影响 TLS 连接，但排查入口不同。

配置 CurvePreferences 时先固定兼容假设

如果业务只要求使用 Go 的默认安全集合，通常让 CurvePreferences 保持空值更省心：默认集合会随 Go 版本演进。当前官方文档注明，Go 1.24 默认包含 X25519MLKEM768，Go 1.26 又加入两个 SecP 混合组。这个策略适合能统一升级客户端与服务端的系统。

如果必须锁定部署能力，例如老旧对端不接受新组，才显式写集合。但显式集合会把“未来默认值变化”变成“由应用自己维护”的责任。迁移时至少回答三个问题：对端是否支持这些组、部署中的 Go 版本是否定义这些常量、失败时是否还有共同的传统组。

package tlscfg

import "crypto/tls"

func ConfigForMixedGroups() *tls.Config {
	return &tls.Config{
		// 显式保留传统组，避免对端尚未支持混合组时完全没有交集。
		CurvePreferences: []tls.CurveID{
			tls.X25519MLKEM768,
			tls.X25519,
			tls.CurveP256,
		},
	}
}

这里的数组表达“允许集合”，不要把它当成跨版本都有效的强制优先级。若编译环境还没有某个新常量，先确认 Go 工具链版本，再决定升级、留在默认集合，或暂时只写已有的传统组。

用握手结果回看实际协商对象

配置文件只能说明“应用愿意支持什么”，不能证明一次连接最终选中了什么。握手成功后读取 ConnectionState().CurveID，把数值转成名称记录到结构化日志；失败时再结合错误文本判断是没有共同组、版本不兼容，还是别的 TLS 层问题。

func negotiatedGroup(conn *tls.Conn) string {
	state := conn.ConnectionState()
	// CurveID 是本次握手实际使用的组；空字符串只表示记录格式异常。
	if state.CurveID == 0 {
		return "none"
	}
	return state.CurveID.String()
}

不要因为客户端和服务端都“写了同一个列表”就跳过检查。代理、不同 Go 版本和服务端默认策略都可能改变实际交集。四个可复现的验收字段是：客户端集合、服务端集合、Go 工具链版本、握手后的 CurveID。

把配置变更纳入四项验收矩阵

这套矩阵比只改一个参数更可靠。混合后量子组属于密钥交换能力，不能用修改证书或放宽 CipherSuites 来替代。生产上线可以先在同版本、同配置的两端记录实际 CurveID，再扩展到异构客户端；一旦出现握手失败，回退到双方都确认存在的传统组，而不是反复扩大配置列表。

常见问题

CurvePreferences 的顺序能当作强优先级吗？

不能把顺序当成稳定的跨版本优先级契约。官方文档说明当前选择由内部偏好规则决定，显式列表更重要的作用是限定支持集合。

CurveID 和 CipherSuite 是一回事吗？

不是。CurveID 表示密钥交换组，CipherSuite 还涉及对称加密和认证组合，排查时应分开记录。

为什么显式配置后新版本默认能力没有生效？

因为显式 CurvePreferences 会覆盖默认集合。想跟随 Go 默认演进，就不要过早锁死列表；想锁定能力，就要自行维护版本兼容矩阵。