限制协议版本与密码套件同时保留兼容性说明

Go 里限制 TLS 兼容范围，要把“协议版本”和“密码套件”分开配置：用 MinVersion、MaxVersion 规定能否使用 TLS 1.2/1.3，用 CipherSuites 只筛选 TLS 1.0–1.2 的套件。一个兼顾新客户端与常见旧客户端的起点通常是允许 TLS 1.2 到 TLS 1.3，并只在确有互操作需求时填写 TLS 1.2 套件列表。

先区分协议版本范围与密码套件范围

MinVersion 表示可接受的最低 TLS 版本，MaxVersion 表示最高版本。当前 Go 的默认最低版本是 TLS 1.2，默认最高版本是该包支持的最高版本；把上下限显式写出，便于审查配置和解释兼容策略。

CipherSuites 只描述 TLS 1.0–1.2 的密码套件，例如 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256。TLS 1.3 的 TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384 等套件不在这个列表的控制范围内。也就是说，既要限制版本又要筛选套件时，两个字段可以同时出现，但它们解决的是两层不同的问题。

用 tls.Config 表达最小兼容策略

下面的配置适合需要明确拒绝 TLS 1.0/1.1、同时保留 TLS 1.3 的场景。列表中的套件只给 TLS 1.2 及以下使用；如果没有明确的旧对端约束，删掉 CipherSuites 让 Go 使用安全默认值，通常更容易跟随标准库的后续调整。

package main

import "crypto/tls"

func compatibleTLSConfig() *tls.Config {
	return &tls.Config{
		// 只允许 TLS 1.2 到 TLS 1.3，拒绝更旧协议。
		MinVersion: tls.VersionTLS12,
		MaxVersion: tls.VersionTLS13,
		// 这些条目只影响 TLS 1.2 及以下，顺序不会改变选择结果。
		CipherSuites: []uint16{
			tls.TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
			tls.TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
			tls.TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
			tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
		},
	}
}

服务端把这个配置交给 tls.Listen 或 HTTP 服务器，客户端则放到 http.Transport.TLSClientConfig。版本协商仍取决于双方交集；如果旧客户端只支持 TLS 1.1，把最低版本设为 TLS 1.2 后握手失败是预期结果，不应靠关闭证书校验来绕过。

按对端能力选择兼容档位

兼容性不是“套件越多越好”。先把接入方按能力分组，再决定配置：

不要设置已被标记为过时且实际无效的 PreferServerCipherSuites 来改变服务端选择顺序。Go 文档说明服务端会根据共同支持情况、硬件和安全因素选择套件，这个字段现在没有作用。

配置生命周期与排错边界

tls.Config 交给 TLS 客户端或服务端后不能再修改；如果不同监听器需要不同策略，应在启动前分别构造配置，或先使用 Clone 再调整副本。排查握手失败时，按“双方最高/最低版本 → TLS 1.2 套件交集 → 证书和主机名验证”的顺序看，能避免把不同层次的问题混在一起。

特别是 InsecureSkipVerify 会关闭客户端对服务端证书链和主机名的默认验证，不能当作兼容性开关。测试自签名证书时，应配置受信任的根证书或实现明确的自定义验证，并把测试配置与生产配置分开。

相关问题

只设置 CipherSuites，能禁止 TLS 1.3 吗？

不能。要限制协议版本，应设置 MaxVersion；密码套件列表本身不控制 TLS 1.3。

为什么配置写了多个套件，结果仍然握手失败？

可能是双方没有共同的协议版本或 TLS 1.2 套件，也可能是证书签名算法、主机名或信任链不匹配，需要分别查看握手错误。

什么时候不应该显式填写 CipherSuites？

当没有明确的旧设备或互操作约束时，保留安全默认值更省维护，也能跟随 Go 对默认套件的更新。