📚 课程目录第1章 TLS基础

1、TLS基础：TLS协议概述、历史与发展

说实话，聊到传输安全，TLS 是绕不开的基石。很多新人觉得它就是个「加个锁」的东西，但实际踩过坑才知道，里面的门道比想象中深得多。我最早接触 TLS 还是在给一个电商平台做接口加固的时候，那会儿差点因为版本问题搞出生产事故。嗯，咱们从根儿上理一遍。

为什么会有 TLS？

TLS 的全称是 Transport Layer Security —— 传输层安全协议。它的前身是 SSL（Secure Sockets Layer），由 Netscape 在 90 年代推出。当时互联网刚起步，HTTP 是明文传输，你想想看，在网络上发个密码、银行卡号，就跟在明信片上写字一样，沿途任何人只要能截获包，都能看得一清二楚。

机密性：数据加密，中间人看不懂。
完整性：防止数据在传输中被篡改。
身份认证：确保你连的是真服务器，不是钓鱼的。

我在项目中遇到过最典型的场景就是内网 API 调用。有团队觉得「内网嘛，没事」，结果被别的租户扫描到端口，直接抓包拿到了明文会话。说白了，网络环境不可信，这是底线思维。

TLS 的演进路线

版本迭代可不是简单的数字加一。每次升级背后都有惨痛的安全事故。我把关键版本和变革点整理了一下：

版本	推出年份	核心变化	现状
SSL 1.0	未公开发布	内部设计，存在严重缺陷	从未使用
SSL 2.0	1995	首次公开，但漏洞极多	1996年已被废弃
SSL 3.0	1996	重新设计，为 TLS 奠基	2015年因 POODLE 攻击彻底废弃
TLS 1.0	1999	基于 SSL 3.0 标准化，增补细节	已退役，不再推荐
TLS 1.1	2006	防御 CBC 攻击，更严格的 IV 处理	已退役，不再推荐
TLS 1.2	2008	引入 AEAD 密码套件，SHA-256 支持	当前主力版本
TLS 1.3	2018	握手从 2-RTT 降为 1-RTT，移除不安全算法	强烈推荐，逐步成为主流

这里有个关键点。TLS 1.3 的握手流程大幅简化，不仅快，而且剔除了很多旧版本的历史包袱。我曾经在升级一个旧支付网关时，硬是被 TLS 1.2 的密钥交换协商坑了一把 —— 对方只支持 DHE，而我们客户端默认开了 ECDHE，结果握手失败。这种事在 TLS 1.3 里几乎不会发生，因为它固定了前向安全的密钥交换。

我的习惯：新项目直接锁定 TLS 1.2 和 TLS 1.3，若因为兼容性问题必须开 1.0/1.1，一定要单独走评审和防火墙隔离。

TLS 协议栈速览

TLS 不是一个单独的算法，而是一套协议族。它分为两层：

记录协议（Record Protocol）：负责分段、压缩、加密和完整性校验。每个记录就是一个数据块。
握手协议（Handshake Protocol）：负责协商加密参数、证书验证、密钥交换。这是最复杂也最关键的环节。

除了握手和记录，还有 Change Cipher Spec 协议（告知对端切换加密参数）以及 Alert 协议（传递错误和告警）。在实际抓包分析时，我最常盯着的是 Handshake 阶段的几组报文：ClientHello、ServerHello、Certificate、ServerKeyExchange、ClientKeyExchange、ChangeCipherSpec、Finished。

    曾经有一次排查 HTTPS 性能瓶颈，我发现每次新建连接都要 100ms 以上。一查，原来是 ClientHello 里带了十几个密码套件，服务器逐个比较，浪费了大量时间。我建议只保留 4-6 个主流套件，延迟直接砍半。你想想看，优化就得从这种细节抠。

一个简单的 TLS 握手现场

为了让你直观感受，下面是一个最简化的 TLS 1.2 握手流程（单向认证）。注意这是简化版，真实情况还有扩展和协商。

Client                                          Server
------                                          ------
1. ClientHello  (支持的版本, 密码套件, 随机数)  ---->
2.                                                <---- ServerHello (选中的版本/套件, 随机数)
3.                                                <---- Certificate (服务器证书链)
4.                                                <---- ServerHelloDone
5. ClientKeyExchange (用服务器公钥加密的预主密钥) ---->
6. ChangeCipherSpec                              ---->
7. Finished (握手消息的 MAC)                     ---->
8.                                                <---- ChangeCipherSpec
9.                                                <---- Finished
--- 后续数据均为加密传输 ---

嗯，这里要注意第 5 步。预主密钥是通过服务器证书里的 RSA 公钥加密的。如果私钥泄露，整个会话就能被解密。所以 TLS 1.3 强制使用 (EC)DHE 实现前向安全，即使私钥日后泄露，之前记录的流量也无法被解密。我在做金融项目安全审计时，最强调的就是这个点：生产环境禁止使用 RSA 密钥交换。

避坑指南：我曾经碰到一个团队，为了省一次证书验证，在微服务间通信里把 TLS 的双向认证改成了只校验客户端 IP。结果被攻击者在内网伪造 IP 后直接中间人。证书验证不能省，这是身份的唯一凭证。

关于版本选择，我的建议

如果能控制客户端和服务端，直接上 TLS 1.3。握手更快，安全更扎实。
如果必须支持老客户端（比如 Windows 7 上的 IE），保底是 TLS 1.2，但禁用 CBC 模式密码套件和 RC4。
不要主动开启 SSL 3.0 / TLS 1.0 / TLS 1.1。如果有遗留系统必须对接，通过单独的网关或反向代理做协议转译，而不是降低整个服务的安全水位。

搞清楚了这些，后面的令牌化传输才有根基。令牌本身在传输过程中也是依赖 TLS 保护的，如果 TLS 层就漏了，再好的令牌方案也白搭。说一千道一万，传输安全从选择一个正确的 TLS 版本开始。

这份结构图把 TLS 的诞生驱动力、分层设计、三种安全属性以及版本迭代串在了一起。你看，核心就是围绕「防窃听、防篡改、防假冒」这三件事展开，每一层的设计都是为了堵上某一种攻击手段。

到了实际部署阶段，版本选择往往是最大的坑。TLS 1.2 和 1.3 虽然名字只差 0.1，但内部实现差异巨大。我习惯在 Nginx 里这样锁定：

ssl_protocols TLSv1.2 TLSv1.3;

仅此一行，能挡住大量基于旧版本漏洞的扫描。嗯，别看它简单，效果非常直接。

    你可能会问：TLS 1.3 这么好，为什么不能立刻全面铺开？我在一个制造业 IoT 项目里遇到过，现场的传感器嵌入式系统只支持 TLS 1.0 且无法 OTA。最后方案是在边缘网关上做协议降级，但用防火墙隔离了公网访问。妥协方案也要有底线。

总的来说，TLS 不是银弹，但它是所有网络安全通信的起点。把版本选对、握手流程吃透、密钥交换方式搞清楚，后面的令牌化传输才能放心往上做。