3.3 一个故事讲完HTTPS
从直接用服务器公钥保护所有数据走到 TLS 握手认证、密钥派生与 AEAD 记录保护分工，沿 HTTPS 的身份与机密性边界诊断连接。
学习目标
- 能沿 ClientHello、参数协商、证书验证、密钥派生和加密 HTTP 记录追踪一次 TLS 1.3 握手
- 能解释非对称密码如何承担身份/密钥协商，对称 AEAD 如何承担高效记录保护
- 能在正常、边界和故障场景中回答：主机名不匹配或记录被篡改时，客户端应在哪个边界拒绝
3.3 一个故事讲完HTTPS
本页依据刘欣《码农翻身》（2018 年第 1 版）及出版社公开书目信息，独立重构 3.3 一个故事讲完HTTPS。正文、代码、图示、实验和练习都是本课程重新设计的教学材料，不复制原书正文、插图、练习答案或代码。
先想象两个人要交换一箱文件：先确认对方拿的是可信身份证，再共同生成一把只用于这次对话的锁，之后用这把锁快速保护每一箱文件。身份证不负责搬运所有文件，快速的锁也不能替身份证证明对方是谁。
本章解决的是“网页数据如何同时获得身份确认、机密性和完整性”。没有认证，窃听者可以伪装成服务器；没有完整性，内容会在路上被改写；把慢的身份工具拿来加密所有正文，又会让大数据传输低效。HTTPS 的验收必须把 HTTP、TLS 握手和记录保护分层。
三个会让 HTTPS 失真的陷阱
七个目录节点到 TLS 证据
3.3 一个故事讲完HTTPS
总合同是：HTTPS 在 HTTP 之下建立经过身份验证的 TLS 通道；握手协商参数、验证端点并派生密钥，随后每条 HTTP 记录都要通过机密性与完整性验证。不能用浏览器地址栏的锁图标替代这些证据。
总有一种被偷窥的感觉
↡在未保护的网络上，旁观者可以读取请求内容、响应内容、连接目标或通信时间等信息的威胁感。是机密性问题的直觉入口。TLS 记录加密减少内容暴露，但长度、时间和端点等元数据仍可能泄露；设计时要知道协议保护了什么，没有保护什么。
RSA：非对称加密
↡使用公钥和私钥组成一对不同密钥的密码机制，适合签名验证或保护小规模秘密，不适合批量正文加密。在现代 TLS 中更多承担签名验证等身份边界，具体握手还要遵循协商的密钥交换与签名算法。不要把“有 RSA”当成协议版本或安全性的充分说明。
非对称加密 对称加密
↡先用非对称机制建立或确认共享秘密，再用双方共享的对称密钥高效保护大量记录的分工。是性能与信任边界的组合：前者解决“怎样确认并建立秘密”，后者解决“怎样快速保护正文”。两者的算法、密钥用途和生命周期不能混写。
中间人劫持
↡攻击者插入客户端与真实服务器之间，转发或修改通信并试图让双方误以为彼此直接连接的攻击。能否成功取决于身份验证是否严格，而不是取决于页面是否使用了某个加密算法。主机名、证书用途、链和密钥握手都必须落到客户端的拒绝条件中。
你到底是谁
↡客户端通过证书、主机名、信任链和握手签名确认当前端点确实代表请求的服务器身份。是 TLS 的认证问题。客户端应把请求主机名带入验证，不能因为通道“加密了”就关闭校验；开发环境的临时例外也必须隔离，不能成为生产默认值。
HTTPS
↡把 HTTP 消息放进经过 TLS 保护的连接中，获得端点认证、记录机密性和记录完整性的 Web 通信方式。不是一种单独的正文加密算法。它继承 HTTP 的语义，同时依赖 TLS 的握手与记录层；应用仍要处理认证、授权、Cookie、缓存和敏感数据生命周期。
最小握手与记录合同
clientHello(host, versions, suites)
serverHello(selectedParams, certificate, signature)
verify(host, chain, validity, keyUsage)
trafficKeys = derive(sharedSecret, transcript)
protectHttp(record, trafficKeys, sequence)合同要求把请求主机名、协商参数、证书验证结果、握手 transcript、密钥阶段和记录序号保存为可审计证据。真实实现由 TLS 库处理密码细节，应用不应自行拼装密码协议；应用只配置可信根、主机名验证和失败策略。
五步复核一次 HTTPS 连接
1. 发送 ClientHello 并固定意图
记录目标主机名、支持版本、密码套件、扩展和随机值。基线连接使用受信主机；边界场景改变主机名或版本，预期是协商结果与请求意图一致，而不是接受任意降级。
Lab
TLS 身份与记录实验
只改变主机身份或记录内容，观察拒绝发生在握手前、应用数据前还是记录交付前。
主机名匹配，证书链可信，记录标签通过
host=shop.example → chain ok → keys derived → HTTP record accepted
判定
accept：身份、机密性和完整性闭环
当前样本：可信连接；保存主机名、证书链摘要、协商参数、记录序号和应用可见性。
正常、边界与故障证据矩阵
| 样本 | 只改变的变量 | 预期判定 | 必存证据 |
|---|---|---|---|
| 正常 | 主机名匹配、链可信、记录未改 | 握手完成，HTTP 记录验证通过 | 主机名、链摘要、套件、记录状态 |
| 边界 | 版本/套件策略或证书接近过期 | 按策略协商或拒绝，原因可解释 | 协商选择、有效期、策略命中 |
| 故障 | 主机名不匹配或记录标签失败 | 在应用数据前/交付前拒绝 | 首个失败检查、方向、错误状态 |
故障诊断：先分辨身份、握手还是记录
- 身份侧：查请求主机名、SAN、有效期、用途和信任链；链可信但主机名错仍必须拒绝。
- 握手侧：查版本、套件、密钥交换组、transcript 和签名；不要只看“握手成功”日志。
- 密钥侧：查阶段、方向、序号和重协商/更新边界；应用不应自行复制密钥派生。
- 记录侧：查 AEAD 标签、关联数据、顺序和截断；认证失败的记录不能进入 HTTP 解析器。
如果浏览器提示证书错误，先分离时钟、主机名、链和用途；如果握手成功但内容异常，查记录认证和应用解析；如果连接被降级，查版本策略和中间设备。每次只改变一个检查项，并重放可信基线。
术语表
名词解释
本章出现的专业名词，用大白话再讲一遍。
- 总有一种被偷窥的感觉
未保护网络中旁观者可以读取内容或观察通信模式的威胁直觉。
- RSA：非对称加密
使用公钥和私钥的一对密码机制，适合身份/小秘密边界，不适合批量正文。
- 非对称加密 对称加密
用非对称机制建立信任与秘密，再用对称密钥高效保护大量记录的分工。
- 中间人劫持
攻击者插入双方之间转发或修改通信并伪装成直接连接的攻击。
- 你到底是谁
客户端用主机名、证书、信任链和握手签名确认端点身份的问题。
- HTTPS
把 HTTP 放进 TLS 保护连接中，获得认证、机密性和完整性边界的通信方式。
练习
练习
问题 1： 为什么 HTTPS 不直接用服务器 RSA 公钥加密所有响应正文？
问题 2： 证书链可信但主机名不匹配，为什么仍必须拒绝？
问题 3： 修改本页“TLS 身份与记录实验”的故障场景，使它显示一次主机名不匹配和一次记录认证失败，并说明重置后应恢复哪些状态。
本页小结
- HTTPS 把 HTTP 放进经过认证的 TLS 通道。
- 非对称机制解决身份与秘密建立，对称 AEAD 保护大量记录。
- 主机名、证书链、握手 transcript 和记录标签都属于拒绝边界。
- 认证失败的记录不能交给 HTTP 应用解析。
读完后的自测问题是：面对“证书链可信但主机名不匹配”或“记录标签失败”，你能否指出客户端应在应用数据前后的哪一步拒绝，并说出应保存的证据？