模块七 · 网络安全
TLS 深入
前面学习的加密、消息认证、签名和证书，怎样在HTTPS连接中协同工作？本章先画清一次TLS 1.3握手，再区分普通握手、恢复和0-RTT。
本章要解决的问题：前面学习的加密、消息认证、签名和证书，怎样在HTTPS连接中协同工作？本章先画清一次TLS 1.3握手，再区分普通握手、恢复和0-RTT。
本章的证据来源：TLS 1.3以RFC 8446为准。教材§8.6，纸书423–426页，用于理解TLS目标与基本设计；其中“类TLS”和旧式RSA示例不能直接当成TLS 1.3流程。旧稿证书输出本次未重新采集，缺少原始证书文件，不作已复核证据。
先从一个例子理解概念
你打开一个HTTPS网站。浏览器既要防止别人读到传输内容，也要确认自己正在与目标域名对应的服务器通信。只把内容加密，还不足以解决身份冒充。
身份认证与密钥建立
身份认证是验证对方是否有权代表目标身份；密钥建立是让双方得到用于保护本次通信的秘密材料。证书把身份与公钥联系起来，但客户端还要检查证书链、目标名称等，并验证服务器在握手中的签名。
握手密钥与应用数据密钥
握手是传应用内容前协商参数、建立密钥并认证的过程。TLS 1.3分阶段派生密钥：保护握手消息的密钥和保护应用数据的密钥不是一个不加区分的“对称密钥”。
Finished是对握手记录的带密钥验证值，用来检查握手内容及对方拥有相应密钥。它不是“发送一张证书”或“发完文件”。
先看普通的证书认证全握手
下面限定为服务器证书认证、使用临时(EC)DHE密钥交换、不要求客户端证书、没有HelloRetryRequest的全握手。花括号内的消息用握手密钥保护：
客户端 服务器
ClientHello + key_share ────────────────────→
←────────────────── ServerHello + key_share
←────────────────── {EncryptedExtensions}
←────────────────── {Certificate}
←────────────────── {CertificateVerify}
←────────────────── {Finished（服务端）}
验证证书、签名和服务端Finished
{Finished（客户端）} ───────────────────────→
应用数据按对应的应用流量密钥保护顺序是服务端先发送Finished，客户端核对后发送自己的Finished。 服务端在发送ServerHello后可以根据密钥交换材料派生握手密钥；客户端收到ServerHello后也能派生，所以后续证书消息可以加密传输。
计算出握手密钥并不等于对端已可信。客户端还必须完成证书、签名和Finished等验证；不能把“先计算密钥”和“先信任对方”混为一谈，也不能要求在解出证书之前先验证这张证书。
这里的1-RTT是什么意思
不计DNS和TCP建连，在上述正常流程中，客户端发送ClientHello后，经一次往返拿到服务器的一组握手消息，随后发送自己的Finished及应用数据。因此通常称为1-RTT握手。
这不表示所有TLS 1.3流程都只有一次往返。参数不合适时可能出现HelloRetryRequest；应用响应还要另算传播与处理时间。
证书和握手签名各证明什么
| 检查 | 解决的问题 |
|---|---|
| 证书链及受信任锚点 | 该公钥绑定是否经客户端信任的体系确认 |
| 目标服务名称、有效期、用途等 | 证书是否适用于本次目标与用途 |
| CertificateVerify握手签名 | 对方是否持有与证书公钥对应的私钥，并绑定本次握手 |
| Finished | 对方是否拥有相应握手秘密，握手记录是否一致 |
信任锚点来自客户端的可信配置，可以是系统/浏览器提供，也可以由用户或管理员配置。一张证书自签发，不足以让它受信任。 吊销状态检查的实际方式与失败处理还依客户端实现及策略，不能把所有实现描述成统一五步、任一步固定断开。
旧稿展示过一条标为Cloudflare的三级证书链。这只是旧稿历史转述，本次没有原始证书或独立采集，不能据此确认当前链条、叶证书签发时间或“有效期约90天”。到期日期本身也不能计算出完整有效期，需要起始日期。
前向保密：要看使用了什么密钥交换
前向保密指长期秘密将来泄露时，过去会话内容仍受保护。临时(EC)DHE利用每次握手的临时秘密建立密钥，在正确实现并销毁临时秘密等条件下提供这种保护；原因不只是“密钥没有直接发上网”。
TLS 1.3支持三种基本密钥交换模式：
| 模式 | 理解方式 |
|---|---|
| (EC)DHE | 使用临时Diffie-Hellman材料，普通证书认证全握手常用 |
| PSK-only | 使用预共享密钥，没有这次临时DH交换；不具有同样的前向保密性质 |
| PSK + (EC)DHE | 结合预共享密钥与本次临时DH交换 |
因此“TLS 1.3所有模式都强制前向保密”不准确。TLS 1.3移除了静态RSA密钥传输等旧机制，但PSK-only与早期数据仍需单独讨论。临时DH与普通、长期不变的DH密钥也不能混写。
恢复与0-RTT
恢复连接可利用之前建立的PSK。允许0-RTT时，客户端不等服务器这次响应就发送早期应用数据，并不意味着握手已经零往返完成。
早期数据没有普通1-RTT数据同样的前向保密与防重放保证。服务端可能拒绝早期数据，应用也需要处理重放风险；不能把它当作可安全重发任何业务操作的普遍优化。
| 情况 | 往返说明 |
|---|---|
| TLS 1.2典型证书全握手 | 通常2 RTT，不代表恢复握手也一样 |
| TLS 1.3普通全握手 | 通常1 RTT，HelloRetryRequest会增加往返 |
| TLS 1.3的0-RTT早期数据 | 客户端可提前发送，握手仍继续且有额外安全限制 |
TLS 1.3密码套件指定AEAD算法与HKDF使用的散列，密钥交换组和签名算法另外协商，不能把套件名称解释成同时包含这三项。
代理是否解密，要看实际连接
代理可以只转发TLS密文，也可以终止客户端TLS、再与真实服务器建立另一条TLS。后者若要让客户端接受其代签证书，需要相应可信配置等条件。
存在TUN或代理本身不能证明发生TLS解密。 判定需要检查连接、证书及信任配置等证据；不能仅凭“根证书是谁安装的”排除所有冒充方式。
本章小结
| 结论 | 条件 |
|---|---|
| TLS协同提供机密性、完整性和对端认证等保护 | 需正确配置与验证 |
| 普通TLS 1.3全握手中服务端Finished先于客户端Finished | 本章图示的限定流程 |
| 握手密钥先于解读加密的证书消息建立 | 建立密钥不等于身份验证完成 |
| 通常1 RTT不含TCP/DNS，也不涵盖重试等分支 | 不能与应用响应时间混算 |
| 前向保密须区分临时(EC)DHE、PSK-only与早期数据 | 不是无条件的版本属性 |
| 0-RTT提前发送数据，存在重放等风险 | 握手仍继续 |
| 原证书链输出尚未复核，代理存在不证明TLS已被终止 | 历史观察与推断分开 |
自测题
7 题 · 先自己答，再展开对照
为什么只加密还不足以确认服务器身份？
如果没有可靠身份认证，可能与冒充者建立加密连接。证书链、目标身份、握手签名及Finished等检查共同保护本次认证。普通TLS 1.3证书全握手中，哪一方先发送Finished？
服务端先发其Finished，客户端验证后再发送自己的Finished。本章图示不含客户端证书认证等可选分支。必须先验证证书才能计算TLS 1.3握手密钥吗？为什么？
不是。ServerHello之后可派生握手密钥，后续证书消息用它保护。计算密钥不表示身份已验证，客户端仍需完成认证检查。“TLS 1.3通常1-RTT”包含TCP建连吗？是否涵盖所有分支？
不含DNS与TCP建连。普通全握手通常1 RTT；HelloRetryRequest等分支会增加往返，应用响应另算。TLS 1.3的三种密钥交换模式是什么？是否都具有同样的前向保密性质？
(EC)DHE、PSK-only、PSK+(EC)DHE。临时DH在适当条件下提供前向保密；PSK-only和0-RTT早期数据不能获得同样的性质。0-RTT表示握手已完成吗？需要注意什么风险？
不表示，客户端可以提前发送早期数据，握手仍继续。早期数据有重放风险且安全性质不同，服务器可能拒绝，应用必须按其业务语义处理。机器使用TUN代理，就说明HTTPS内容被代理解密了吗？
不说明。代理可能只转发密文，也可能终止TLS；要结合连接、证书和信任配置等证据判断，不能只看代理是否存在。
参考资料与适用范围
- 《计算机网络：自顶向下方法（原书第8版）》§8.6，纸书423–426页（PDF442–445页）：TLS目标和简化设计模型，不替代TLS 1.3规范。
- RFC 8446 §2及图1：TLS 1.3全握手顺序
- RFC 8446 §2.2–2.3：PSK恢复、早期数据及限制
- RFC 8446 §4.4与§7.1：认证消息与分阶段密钥派生
修订核对日期：2026-10-13。图示只覆盖注明的正常全握手；旧稿证书链属于未重新采集的历史观察。版本特性、密钥交换模式和客户端验证策略须分别理解。