第1章 TLS基础：协议概述、历史版本、HTTPS安全模型
1.1 什么是TLS？
TLS，全称 Transport Layer Security，翻译过来叫「传输层安全协议」。说白了，它就是给网络通信加了一把锁。你想想看，HTTP 数据在网络上裸奔，谁都能抓包看到内容，这哪儿行？TLS 就是来解决这个问题的。
它工作在传输层之上、应用层之下。具体位置是这样的：
- 应用层——HTTP、FTP、SMTP 等协议
- TLS 层——握手协议、记录协议、警报协议
- 传输层——TCP
- 网络层——IP
TLS 提供的核心能力有三项：
- 加密：数据在传输过程中是密文，抓到了也看不懂。
- 完整性：数据如果被篡改，接收方能立刻发现。
- 身份验证：客户端能确认自己正在和真正的服务器通信，而不是冒牌货。
审计要点：TLS 不是某个具体的加密算法，而是一个协议框架。它组合了对称加密、非对称加密、哈希算法等多种密码学工具。合规审计时，我们关心的正是这个「组合」是否合理——比如用了过时的算法、配置了弱的密钥长度，这些都算不合规。
1.2 TLS 的历史版本
TLS 的前身是 SSL，由 Netscape 在 90 年代开发。我刚开始接触安全工作时，SSLV3 还没完全退役，那时候的配置项现在看来简直是灾难。版本演进过程并不复杂，但每个节点都很关键。
| 协议版本 | 发布时间 | 状态 | 关键问题 |
|---|---|---|---|
| SSL 1.0 | 1994（未公开） | 已废弃 | 从未正式发布，存在严重安全缺陷 |
| SSL 2.0 | 1995 | 已废弃（RFC 6176） | 无防篡改机制、弱密钥、易受中间人攻击 |
| SSL 3.0 | 1996 | 已废弃（RFC 7568） | POODLE 攻击，降级风险极高 |
| TLS 1.0 | 1999 | 已废弃（RFC 8996） | BEAST 攻击，CBC 模式弱点 |
| TLS 1.1 | 2006 | 已废弃（RFC 8996） | 修复了 CBC 攻击，但改进有限 |
| TLS 1.2 | 2008 | 广泛使用 | 支持 AEAD、GCM、SHA-256，配置灵活 |
| TLS 1.3 | 2018 | 推荐使用 | 移除不安全算法，握手缩短为 1-RTT |
避坑指南：在合规审计中，SSL 2.0/3.0 和 TLS 1.0/1.1 属于「一票否决」项。我记得有一次做金融客户审计，对方生产环境居然还开着 TLS 1.0，原因是某个老版收银机固件只支持 TLS 1.0。最后推动他们升级固件花了整整两个月——这种历史债，越早还越好。
这里有个细节值得注意：TLS 1.3 和 TLS 1.2 不是简单的增量升级。1.3 砍掉了大量过时算法（如 RC4、3DES、静态 RSA 密钥交换），并且将握手从 2-RTT 缩短到 1-RTT。我个人的建议是：新系统直接上 TLS 1.3；存量系统至少要关闭 1.0 和 1.1，1.2 作为兜底。
1.3 HTTPS 安全模型
HTTPS 就是 HTTP over TLS。严格来说，HTTPS 不是一个单独的协议，而是 HTTP 和 TLS 的组合。它的安全模型可以拆成三个层面来看。
1.3.1 混合加密机制
TLS 没有单纯只用一种加密方式。它用了「非对称加密 + 对称加密」的混合方案。为什么这么设计？原因很简单：
- 非对称加密（如 RSA、ECDHE）：慢，但适合安全地交换密钥。
- 对称加密（如 AES-GCM、CHACHA20）：快，但密钥分发是个难题。
TLS 的做法是：先用非对称加密安全地协商出一个对称密钥（称为「会话密钥」），然后用这个对称密钥加密后续的所有数据。这样一来，握手阶段的安全性由非对称加密保障，数据传输阶段的高效由对称加密保障。
经验之谈：有些人会问：「为什么不用纯非对称加密？」答案是性能。我在项目中测过一次，纯 RSA 加密传输 1MB 数据耗时是对称加密的 200 倍以上。对于高并发服务，这个差距是致命的。
1.3.2 证书体系与 PKI
身份验证靠的是数字证书。服务器向客户端出示证书，客户端验证证书是否由可信的 CA（证书颁发机构）签发。这个信任链长这样：
- 根 CA：浏览器/操作系统内置信任，自签名。
- 中间 CA：由根 CA 签发，用于日常运营。
- 服务器证书：由中间 CA 签发，绑定域名和公钥。
验证过程包含：证书链是否完整、证书是否过期、域名是否匹配、是否被吊销（CRL/OCSP）。
注意：证书过期是合规审计中最常见的问题，没有之一。我见过某大厂因为证书过期导致线上服务中断 40 分钟——监控系统居然没报警。所以建议配置自动续签（如 ACME/LetsEncrypt），并设置证书到期前 30 天、7 天的多级告警。
1.3.3 TLS 握手流程（简化版）
以 TLS 1.2 的一次完整握手为例，核心步骤是：
- ClientHello：客户端发送支持的 TLS 版本、密码套件列表、随机数。
- ServerHello：服务端选定版本和密码套件，返回自己的随机数和证书。
- 证书验证：客户端验证服务端证书的合法性。
- 密钥交换：客户端用服务端公钥加密一个预主密钥（Pre-Master Secret），发给服务端。双方各自算出相同的会话密钥。
- Finished：双方发送加密的 Finished 消息，确认握手成功。
TLS 1.3 把这个过程压缩到了 1 次往返（1-RTT），并且移除了静态 RSA 密钥交换，全面采用前向保密的 ECDHE。什么意思呢？就是即使私钥泄露，之前的会话也不会被解密。
合规视角：审计时重点检查密码套件是否支持前向保密（如以 ECDHE 开头的套件）、是否还有静态 RSA/DH 套件、是否启用了 TLS 1.3。这些直接决定数据泄露后的影响范围。
1.4 一张图看懂 TLS 协议架构与安全模型
下面这张图把 TLS 的协议栈位置、内部组成和安全模型放在了一起。你可以看到数据从 HTTP 往下走，经过 TLS 层的握手、记录、警报三个子协议，最终落到 TCP 上。右侧展示了混合加密和证书验证的协作关系。
1.5 合规审计视角下的 TLS
讲完基础，我们来聊聊审计。TLS 合规审计的核心就三件事：
- 版本合规：是否关闭了所有不安全版本（SSL 全系列、TLS 1.0/1.1）。
- 密码套件合规：是否只使用了强套件（支持前向保密、AEAD 模式）。
- 证书合规：证书是否有效、链是否完整、是否使用了可信 CA。
国内很多合规标准（如等保 2.0、金融行业标准 JR/T 0184）对 TLS 版本和密码套件都有明确要求。我个人习惯的做法是：先拿工具扫一遍全站的 TLS 配置，生成基线报告，再对照标准逐条打标。这样不容易遗漏。
快速检测命令：用 OpenSSL 检查目标站点支持的 TLS 版本和密码套件。
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3
openssl ciphers -v 'ECDHE+AESGCM:!aNULL:!eNULL'看到输出里出现 TLSv1.2 或 TLSv1.3，并且没有 SSLv3、TLSv1.0 这些字样，才算是初步过关。
曾经踩过的坑：有一次审计发现某个内部系统的 TLS 配置全是绿的，但证书链中间少了一级。客户端（比如 Java 应用）直接报错 PKIX path building failed。技术人员查了两天，最后发现是部署时只贴了服务器证书，忘了贴中间 CA。从那时起，我每次审计都会额外检查「证书链完整性」这一项。
TLS 基础的内容就聊到这儿。记住三个关键词：版本、套件、证书。后面的章节我们会深入到每个细分域——密码套件怎么选、握手流程怎么审计、证书生命周期怎么管理。先把地基打牢。