TLS协议基础：从诞生到实战
聊TLS证书密钥管理，得先搞明白TLS协议本身是个什么东西。说白了，它就是互联网上最常用的那层加密管道——你刷网银、登GitHub、连K8s API Server，底层全是TLS在撑着。我刚开始做运维那会儿，TLS还叫SSL，很多人搞混这俩名字。嗯，咱们先把这事理清楚。
TLS发展历史
TLS的历史绕不开它的前身SSL。简单梳理几个关键节点：
- 1994年 - Netscape发布了SSL 1.0，但没公开就废了。有严重安全问题，胎死腹中。
- 1995年 - SSL 2.0发布，开始商用。嗯，但它漏洞多到发指，现在没人敢用。
- 1996年 - SSL 3.0发布。这是我最早接触的版本，当时觉得挺安全。实际上现在看，也不行。
- 1999年 - TLS 1.0发布（相当于SSL 3.1）。名字从SSL换成了TLS，但内核还是一脉相承的。
- 2006年 - TLS 1.1发布。加了防CBC攻击的机制，但改动不大。
- 2008年 - TLS 1.2发布。这是目前兼容性最广的版本，很多老系统现在还在跑。
- 2018年 - TLS 1.3发布。大改版，握手少了一半，安全性也上了一个台阶。
我在实战项目中见过最坑的情况：有客户硬要在2023年还开SSL 3.0，理由是“老设备兼容”。我直接说：这跟没锁门有什么区别？最后花了两周迁移到TLS 1.2才算完。
重要警告：SSL 2.0、SSL 3.0、TLS 1.0、TLS 1.1这几位“老前辈”，全部已经正式废弃。2023年主流浏览器和系统默认禁用它们。别想着图省事留着，合规审计直接给你打回。
TLS 1.2 vs TLS 1.3
这两个版本现在并存，但差异不小。我直接列个表对比，你一看就懂。
| 对比维度 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| 握手次数 | 2-RTT（两轮往返） | 1-RTT（一轮往返），0-RTT 模式可选 |
| 支持的密码套件 | 37个（历史包袱多） | 仅5个安全的（精简化） |
| 密钥交换 | RSA、DH、ECDH | 仅支持 (EC)DHE，强制前向安全 |
| 数字签名 | 可以握手过程中单独发 | 签名隐藏在KeyShare消息里 |
| 降级保护 | 有，但不强 | 内置降级防护机制 |
| 会话恢复 | Session ID / Session Ticket | PSK + 0-RTT，更轻量 |
| 不可协商的算法 | 很多 | 压到最少，减少攻击面 |
| 部署现状 | 仍占多数，但正在退场 | 增长极快，是推荐版本 |
我个人习惯：新系统能上TLS 1.3就直接上。别犹豫。有一次在某个金融项目里，客户坚持要兼容TLS 1.2，结果握手延迟从80ms飙升到200ms。支付接口每慢一秒，转化率掉一截。你想想看，这影响多大。
核心建议：强制TLS 1.3 + 备选TLS 1.2。禁用1.2以下所有版本。这是当前安全基线的第一步。
TLS握手过程概览
握手是TLS最核心的部分。客户端和服务器在正式开始加密传输前，先要通过握手协商出：用什么加密算法、交换什么密钥、验证对方身份。我画了个简化的流程图，你看完整链路就清楚了。
我拿实际场景拆解一下这个握手过程：
- 客户端打招呼 - 发ClientHello，带上支持的TLS版本、密码套件列表、随机数。像我常用的就是TLS_AES_128_GCM_SHA256这些。
- 服务端回应 - 回ServerHello，选定密码套件。同时发证书（就是咱们这门课的核心）给客户端，验证身份。
- 密钥交换 - 双方用(EC)DHE算出共享密钥。这时就能加密后面传输了。
- 验证收尾 - 服务端发Finished，客户端验证。客户端也发Finished，服务端验证。握手完成。
- 加密通信 - 之后所有数据都用对称密钥加密传输。
你会发现，TLS 1.3只用了1次往返就完成了。相较于TLS 1.2的2次，这提升在延迟敏感场景非常明显。我记得有个直播业务，从TLS 1.2切到1.3后，首屏时间少了15%。用户感知不到的提升，但CDN带宽钱省了不少。
避坑指南：我曾经遇到过一个案例——握手始终失败。查了半天，发现是服务端证书链不完整。客户端只拿到叶子证书，但没拿到中间CA证书，验证链断了。所以证书配置时，记得把完整链配好，不要只传一个叶子证书。
好，TLS协议基础这一章就到这儿。核心记住三点：TLS 1.3是当前最优选、握手本质是密钥协商+身份验证、证书是身份凭证。这些搞懂了，后面讲证书签发、密钥轮换、边界管理，你才不会懵。