Go crypto/tls 怎样配置 MLKEM1024 曲线偏好

Go 1.27 可以把 tls.MLKEM1024 加入 tls.Config.CurvePreferences，启用这个密钥交换机制。但字段虽然叫“曲线偏好”，实际表达的是支持集合，切片顺序会被忽略，最终按 Go 内部优先级与对端能力协商。把它写在第一位，不等于强制选中。

官方地址：https://go.dev/

我首先区分新增机制与已有混合机制

阅读 Go 1.27 的 TLS 变更时，我更在意配置含义是否清楚，而不是直接把新常量塞进所有客户端。此次新增支持的是 MLKEM1024，可通过 CurvePreferences 显式启用。依据见 Go 1.27 crypto/tls 发布说明。

tls.MLKEM1024 与 tls.SecP384r1MLKEM1024 是两个不同的 CurveID，后者是混合密钥交换机制，不能因为名字都包含 MLKEM1024 就互换。CurveID 这个名称带有历史因素，现在的 TLS NamedGroup 不只表示椭圆曲线。本文讨论配置与结果读取，不比较密码学强度，不给出未经测量的性能收益。

CurvePreferences 更像允许集合，而不是排序指令

我会把这个字段理解为“当前允许哪些密钥交换机制”。非空配置会显式限定集合，并不是在不断变化的默认集合后面追加一项。若只写 MLKEM1024，就不能指望默认的其他机制自动保留。

官方 Config 文档明确说列表顺序会被忽略，并由内部偏好顺序选择。因而下面的候选集合包含 MLKEM1024 和 X25519，并不意味着两者按代码书写顺序尝试，也不承诺客户端控制服务端的最终选择。

旧代码的风险在于把默认策略冻结了

对我来说，显式配置的好处是范围可见，代价是后续需要维护。如果应用没有明确互操作需求，保留默认集合可能更省维护成本；若业务确实要求启用 MLKEM1024，再有针对性地声明集合。不能仅为了“版本更新了”就给所有服务强制换一份列表。

Go 1.27 还调整了显式混合机制与 tlsmlkem、tlssecpmlkem GODEBUG 项的关系：这些项针对默认集合，不应被当作覆盖任意显式配置的全局开关。部署时应一并检查配置来源，不能把配置文件、代码和环境变量看成互不相关的三份设置。

我会先用兼容候选集合做小范围接入

下面给出一个以 TLS 1.3 为最低版本的客户端配置。使用 X25519 作为另一候选，是示例的互操作选择，并不是默认集合的完整复制，也不代表项目应当照搬。证书链与主机名仍正常校验，没有启用跳过验证。

package kemclient

import (
    "crypto/tls"
    "net/http"
    "time"
)

func NewClient() *http.Client {
    tr := http.DefaultTransport.(*http.Transport).Clone()
    tr.TLSClientConfig = &tls.Config{
        // 本例主动限定 TLS 1.3，不是宣称旧版本也支持该机制。
        MinVersion: tls.VersionTLS13,
        CurvePreferences: []tls.CurveID{
            tls.MLKEM1024,
            tls.X25519,
        },
    }
    // 显式配置 TLS 时保留 HTTP/2 尝试，与密钥交换选择是不同维度。
    tr.ForceAttemptHTTP2 = true
    return &http.Client{
        Transport: tr,
        Timeout: 10 * time.Second,
    }
}

构造器应在请求循环外调用，多次请求共用客户端。若项目已有定制 Transport，应在自己的初始化位置整合字段，不要替换掉原有代理、根证书或连接限制。若使用自定义 DialTLSContext，还要把同样的 TLS 配置交给真正负责握手的拨号器。

这个片段要求包含 tls.MLKEM1024 的 Go 版本。修改 go.mod 并不会自动让旧编译器认识新常量；构建链、实际二进制和部署配置需要一致。本文没有编译或运行代码，示例不附带虚构成功日志。

最终采用什么，以真实握手状态为准

ConnectionState 的 CurveID 表示密钥交换机制；Version 表示 TLS 版本，DidResume 表示是否恢复会话。它们应分别记录，不能从 HTTP/2、密码套件名称或证书类型反推出 MLKEM1024。尤其要区分新建握手与会话恢复场景，不能仅看一次请求成功就认定新机制已启用。

读者可在自己的请求代码中引入 fmt，在 Do 成功取得 resp 后记录必要字段。需要使用 TLS 端点，并在使用完正文后关闭 Body。以下片段的 defer 适合单次请求函数，不宜直接堆在长期运行的大循环中。

// 放在现有 client.Do(req) 成功之后，不代表本任务已执行请求。
defer resp.Body.Close()
if resp.TLS == nil {
    fmt.Println("本次响应没有可用TLS状态")
} else {
    s := resp.TLS
    // 保留字段各自语义，不导出密钥或完整会话信息。
    fmt.Printf("TLS=%s KEX=%s resumed=%t\n",
        tls.VersionName(s.Version), s.CurveID.String(), s.DidResume)
}

如果要求确认完整新握手，应在受控环境使用新建客户端且不启用客户端会话缓存，与明确支持该机制的对端进行比较。观察阶段关心握手错误、实际 CurveID 与兼容性，不应把固定“提升百分比”写进验收标准。这里提供的是读者操作思路，本任务不执行这些测试。

把 MLKEM1024 放到首位能优先选择吗？

不能依赖切片顺序。CurvePreferences 的顺序由内部选择策略替代，应读取实际 CurveID。

只配置 MLKEM1024 是否更合适？

只有明确允许拒绝不支持它的对端时才考虑单一集合。一般迁移要先决定兼容性要求，而不是以列表越短越好。

这会更换服务器证书吗？

不会。密钥交换配置与证书身份验证不是一回事，不要用改 CurvePreferences 修复证书过期或主机名不匹配。

我的结论是：有明确互操作需求时显式启用；没有需求时，不为了新常量冻结默认策略。官方参考：Config 与 CurvePreferences 约定、CurveID 标识、握手状态字段。