Go tls.Config.GetConfigForClient 返回配置后的会话票据密钥处理方案

在 Go 的 TLS 服务端里，GetConfigForClient 返回一份新配置，并不等于自动获得一套新的会话票据密钥。返回配置没有显式设置密钥时，Go 会继续使用原配置的密钥；如果原配置使用自动轮换，也会沿用这条密钥路径。需要隔离会话恢复边界时，应在预先构建好的返回配置上调用 SetSessionTicketKeys。

官方地址：https://go.dev/pkg/crypto/tls/

先分清 GetConfigForClient 改变了什么

这个回调发生在服务端收到 ClientHello 之后。返回 nil 时，当前连接继续使用传给 tls.Server 的原配置；返回非 nil 的 *tls.Config 时，后续握手改用这份配置。它是连接级配置选择，不是让原配置在运行中被修改。

最容易误判的是会话票据：官方文档明确规定，如果返回配置没有显式设置 SessionTicketKey，也没有调用 SetSessionTicketKeys，原配置的票据密钥会继续生效。这样做有利于同一服务的会话复用，但不适合把不同租户、不同认证策略或不同密钥域混在一起。

返回配置要提前构建，回调只负责选择

返回的配置在投入握手后不能再修改。工程上更稳妥的做法是启动时准备好原配置和一个或多个策略配置，回调只根据已经解析的握手信息返回对象，不在回调中临时生成密钥或修改共享字段。

package tlsdemo

import (
    "crypto/rand"
    "crypto/tls"
    "fmt"
)

// buildConfig 预先构建返回配置，避免握手回调中修改正在使用的 Config。
func buildConfig(cert tls.Certificate) (*tls.Config, error) {
    base := &tls.Config{Certificates: []tls.Certificate{cert}}
    selected := base.Clone()
    // 返回配置不再继续嵌套回调，避免把一次选择扩展成递归选择。
    selected.GetConfigForClient = nil

    var key [32]byte
    // 只生成演示用的密钥材料；生产环境应由受控密钥流程提供。
    if _, err := rand.Read(key[:]); err != nil {
        return nil, fmt.Errorf("generate ticket key: %w", err)
    }
    selected.SetSessionTicketKeys([][32]byte{key})

    // 回调只返回已经固定的配置，不修改 base 或 selected。
    base.GetConfigForClient = func(*tls.ClientHelloInfo) (*tls.Config, error) {
        return selected, nil
    }
    return base, nil
}

示例中的 selected 是独立配置，关键不在于回调里写了什么条件，而在于它在服务启动阶段已经完成克隆和密钥设置。真实项目可以把条件判断接到只读路由表上，但不要每次握手都重新生成票据密钥，否则同一服务的恢复行为会变得不可预测。

用 SetSessionTicketKeys 明确密钥轮换语义

SetSessionTicketKeys 接收一个非空数组。第一把密钥用于生成新票据，数组中的全部密钥都可用于解密已有票据，因此可以把新密钥放在首位、旧密钥暂时保留在后面，形成一个可控的轮换窗口。调用这个方法后，自动票据密钥轮换会被关闭，后续轮换由应用负责。

// keys 由密钥管理流程按轮换顺序提供，首项是当前写入密钥。
func applyTicketPolicy(config *tls.Config, keys [][32]byte) error {
    if len(keys) == 0 {
        return fmt.Errorf("ticket keys must not be empty")
    }
    // 第一把密钥签发新票据，其余密钥只用于兼容旧票据。
    config.SetSessionTicketKeys(keys)
    return nil
}

不要在返回配置已经参与握手后再调用这个方法。若多个实例要共享会话恢复，它们需要按照同一顺序维护密钥；若目标是彻底隔离返回配置与父配置，就必须显式提供不同的密钥集合，而不是只调用 Clone。

会话恢复时不要把 VerifyPeerCertificate 当成必经检查

如果返回配置追加了更严格的 VerifyPeerCertificate，首次完整握手可能按预期执行；但官方文档说明，会话恢复不会再次调用这个回调。尤其当返回配置与父配置共享票据密钥时，旧连接建立的会话可能跨配置恢复，从而绕过你以为已经加上的那层检查。

需要覆盖包括恢复连接在内的每次连接检查时，优先考虑 VerifyConnection。如果业务根本不接受会话恢复，可以设置 SessionTicketsDisabled: true。这两个方案的代价不同：前者保留恢复能力但把检查放到更合适的回调，后者直接放弃票据带来的恢复路径。

上线前按四个边界检查

1. 配置边界：回调返回的对象是否在启动阶段准备好，之后没有并发修改。
2. 密钥边界：是否明确继承父配置，还是显式提供独立的密钥数组。
3. 轮换边界：首把密钥、旧密钥保留时间和多实例同步顺序是否有记录。
4. 校验边界：恢复连接是否仍需执行策略检查，若需要就不要把责任放在 VerifyPeerCertificate 上。

把这四项写进配置评审清单，通常比在回调里继续堆条件更容易排查。GetConfigForClient 负责选择连接配置，票据密钥决定恢复范围，验证回调决定每次连接的检查位置，三者要分别设计。

常见问题

返回新的 tls.Config 就会自动生成新票据密钥吗？

不会。返回配置没有显式设置密钥时，原配置的会话票据密钥处理会继续生效。

SetSessionTicketKeys 的第一把密钥有什么作用？

它用于生成新票据；数组中的其他密钥仍可用于解密旧票据，适合做受控轮换。

为什么 VerifyPeerCertificate 没有覆盖恢复连接？

会话恢复不重新验证对端证书，因此该回调不会再次调用。需要每次连接执行的检查应放到 VerifyConnection，或禁用会话票据。

可以在 GetConfigForClient 回调里修改共享配置吗？

不建议。配置参与握手后不应继续修改，应该提前构建不可变的返回对象，让回调只做选择。