Go中配置TLS必须显式设置MinVersion（至少tls.VersionTLS12）、InsecureSkipVerify为false、CipherSuites为AEAD类套件并启用PreferServerCipherSuites，否则默认行为存在降级攻击、证书绕过及弱加密风险。
Go里配TLS不是把证书路径一塞就完事——不显式设MinVersion、InsecureSkipVerify和CipherSuites，默认行为在生产环境大概率不安全。
服务端必须显式限制TLS最低版本
Go的http.ListenAndServeTLS默认允许TLS 1.0和1.1，这两个版本已被NIST和IETF正式弃用。不加约束的服务端可能被降级攻击利用，PCI DSS等合规审计直接拒绝通过。
-
MinVersion必须设为tls.VersionTLS12；MaxVersion建议设为tls.VersionTLS13（除非下游明确要求兼容旧客户端） - 只设
MinVersion是不够的：若客户端只支持1.2，而服务端MaxVersion是1.3，握手仍会协商成1.2；但若没设MinVersion，老旧扫描器或自动化工具可能用TLS 1.0 User-Agent试探成功 - 别依赖“没人用旧协议”——真实生产环境里总有遗留系统或监控探针带弱协议发起连接
客户端Transport必须关闭证书绕过并加载可信CA
很多项目调试时随手写InsecureSkipVerify: true，上线后忘了删。这会导致所有证书校验跳过，中间人可伪造任意证书完成握手，错误日志只报x509: certificate signed by unknown authority这类模糊提示，而非明确失败原因。
-
InsecureSkipVerify必须为false（这是默认值，但显式写出更安全） -
RootCAs字段不能为空：用x509.NewCertPool()加载PEM格式的CA根证书，不是客户端证书，也不是服务端证书 - 若服务端用私有CA（如内部PKI），必须把该CA的根证书内容填进
RootCAs；否则即使证书链完整，也会因无法追溯到信任根而失败 - 常见坑：
ioutil.ReadFile读错路径导致AppendCertsFromPEM返回false却没检查；或误把client.crt当作CA加载
加密套件必须主动锁定AEAD类算法
Go默认启用的套件包含部分已知弱算法（如CBC模式），虽未禁用但协商优先级低。攻击者可通过控制客户端支持列表诱导服务端选择弱套件，跨语言互通时风险放大。
立即学习“go语言免费学习笔记（深入）”；
- 显式设置
CipherSuites字段，只保留带GCM或ChaCha20的AEAD套件，例如：tls.TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - 务必设
PreferServerCipherSuites: true，否则客户端可强制指定低优先级套件，服务端被动接受 - 若服务端用ECDSA私钥，对应套件应选
ECDSA_WITH_系列，否则协商失败 - 不设
PreferServerCipherSuites时，Go服务端会按客户端提供的套件顺序优先选择，等于把安全决策权交给了对方
go-elasticsearch等第三方库的TLS配置要绕过默认封装
像go-elasticsearch这类库提供了CACert字段简化配置，但它只覆盖CA验证，不触碰MinVersion或CipherSuites。如果你需要全链路可控，得穿透封装，手动构造http.Transport再传进去。
- 基础用法：
CACert字段直接传入读取的CA证书字节，适用于标准场景 - 高安全需求时，不要依赖
CACert自动构造tls.Config——它不会设MinVersion，也不会清理弱套件 - 正确做法：自己构建
http.Transport，其中TLSClientConfig完整配置MinVersion、RootCAs、CipherSuites等，再通过elasticsearch.Config.Transport注入 - RabbitMQ的
amqp091-go同理：amqp.DialConfig里的TLSClientConfig必须手动赋值，不能只靠环境变量或配置文件里的ssl_options.cacertfile
最常被忽略的是：MinVersion和CipherSuites必须同时显式设置，缺一不可。前者防降级，后者防弱加密——两者独立生效，不存在“设了A就自动管B”的逻辑。
