TLS协议基础与版本选择
好，咱们正式开始聊TLS。很多同学觉得TLS是“黑盒”，配置一下证书就完事了。但说实话，如果不理解它到底怎么工作的，出起问题来——尤其是审计日志这种关键链路——真的会让人抓狂。
先给个最直白的定义：TLS（传输层安全性）是保护数据在网络传输时不被偷看、不被篡改的协议。它工作在TCP之上，原名叫SSL，后来升级成了TLS。现在大家习惯统称SSL/TLS。注意，SSL 3.0已经彻底淘汰了，千万别再用。
TLS协议的核心作用
为什么审计日志必须依赖TLS？因为审计日志本身是明文日志，如果直接走网络，就等于把内部操作记录“裸奔”出去。TLS干了三件正经事：
- 身份认证：验证服务器（或客户端）是不是真的那个实体
- 加密保护：所有传输内容都被对称密钥加密，无法直接看到明文
- 完整性校验：如果中间有人改了数据包，接收方能立即检测出来
简而言之：没TLS的审计日志传输，等于把内部机密直接贴上了公网公告栏。
我在项目中遇到过一家客户，他们觉得内网传输不需要TLS。结果被一次内部渗透测试逮个正着，所有日志明文被抓包软件一览无余。嗯，从那以后他们的安全架构里再也没有“内网豁免”这一说。
TLS握手过程
这里我不讲长篇协议细节，只拎出手动配置时需要关注的核心环节。你想想看，客户端和服务器第一次建立连接时，需要协商加密方式、交换密钥。这个过程就叫TLS握手。
TLS 1.2和1.3的握手流程差异很大。我个人习惯用一张图来对比理解：
TLS版本对比
现在生产和老系统里，最常见的就是TLS 1.2和TLS 1.3。我把他们核心差异列个表，你用的时候一眼就能看懂。
| 对比维度 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| 握手次数 | 2次RTT（需要两次往返） | 1次RTT（支持0-RTT恢复） |
| 支持的算法套件 | 大量旧套件，需手工禁用弱套件 | 只保留5个强套件，默认安全 |
| 前向安全性 | 可选（需配置ECDHE） | 强制（所有套件都支持） |
| 已知漏洞 | 存在BEAST、POODLE等，需额外加固 | 无已知重大漏洞 |
| 配置复杂度 | 高（需显式禁用弱算法） | 低（默认即安全） |
我个人建议：新项目无脑上TLS 1.3。如果你还在用TLS 1.2，务必检查配置里是否禁用了RC4、CBC、3DES这些老古董。
算法套件怎么选
算法套件是TLS握手协商出的具体加密方案。它长这样：
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256说白了，它决定了用什么对称加密（AES还是ChaCha20）、什么消息认证（GCM还是Poly1305）、什么哈希（SHA256还是SHA384）。
我记得有一次，帮客户排查日志接收延迟，发现他们的TLS 1.2用了CBC模式的套件。你知道CBC模式有个问题，每次解密都要等完整块处理完。换成GCM后，延迟直接降了40%。
避坑指南：我曾经见过一个生产环境，openssl的默认配置里启用了TLS 1.0和TLS 1.1。审计日志接收端也不做版本校验，结果被中间人攻击利用降级漏洞，直接降到了TLS 1.0。日志被事后复盘时才发现早就被截获了。
审计日志场景的特殊要求
嗯，这里要注意。审计日志传输跟普通的Web服务不太一样。它有几个特殊点：
- 日志发送方可能是各类设备——交换机、防火墙、服务器，它们支持的TLS版本参差不齐
- 日志接收端必须是集中式平台——一个平台要同时兼容多个版本的TLS连接
- 不能因为TLS版本不兼容而丢日志——丢了日志等于丢了审计依据
所以实际部署时，我推荐的做法是：接收端启用一个“降级兼容模式”，也就是同时开放TLS 1.2和TLS 1.3。然后给每个发送端配置最合适对应版本的TLS。你想想看，如果一个老交换机只支持TLS 1.2，你强制它只能用1.3，它就连不上了。
核心原则：接收端向下兼容，发送端取最高支持版本。这样做既保证安全，又保证不丢日志。
最后补充一句关于证书的事情。不管用TLS 1.2还是1.3，证书体系本身没变。对审计日志来说，建议用企业内部CA签发的证书，别用自签名证书。自签名证书在审计链路里不好做验证，出问题时也不好追查。