kp-024 HTTPS 与 TLS：握手、证书与混合加密

注：本文基于模型知识整理，建议结合权威教材与 RFC 原文核对细节。

一句话定义

HTTPS 是「HTTP over TLS over TCP」的组合：在 TCP 之上、HTTP 之下插入 TLS（Transport Layer Security，传输层安全协议），用混合加密、完整性校验与证书认证，为明文协议补上机密性、完整性与身份认证三重保障。

为什么重要

明文 HTTP 有三大风险，各自都有现实例子：窃听——公共 Wi-Fi 上抓包即可看到登录密码与 Cookie；篡改——中间设备向页面注入广告、劫持跳转链接；冒充——攻击者伪造「银行官网」诱导输入密码。TLS 同时封住这三类风险，现代浏览器已将 http:// 站点标记为「不安全」，全网 HTTPS 化是既成事实。读懂握手与证书，也是看懂 HTTPS 抓包（kp-034）和排查证书报错的前提。

前置知识

建议先读 kp-023《HTTP》，掌握请求-响应模型与明文报文结构；对称加密与非对称加密的原理与取舍，可在 kp-031《密码学基石》中展开，本章只要求知道「公钥加密、私钥解密」与「对称密钥分发难」这两个常识。

核心概念

协议栈位置：TLS 夹在应用层与传输层之间，HTTPS 默认 443 端口；对上把 HTTP 报文整体加密后再交付 TCP，对下完全透明地使用 TCP 的可靠传输。
混合加密分工：非对称加密（如 ECDHE 密钥交换）只用于协商对称会话密钥；真正的数据传输用对称加密（如 AES-GCM）。必须混合的原因：非对称算法比对称慢几个数量级，逐条消息做公私钥运算性能不可接受；而对称密钥「如何安全地发给对方」的难题，恰好由非对称的密钥交换解决。AES-GCM 属于 AEAD（authenticated encryption with associated data），同时提供加密与完整性校验。
证书与 CA 信任模型：站点证书由 CA（certificate authority，证书颁发机构）签名背书；实际链条是根 CA、中间 CA、站点证书逐级签名，浏览器与操作系统内置受信任的根证书库，任何站点证书最终都要能回溯到某个内置根。
HSTS（HTTP Strict Transport Security）：站点通过响应头声明「此后只允许 HTTPS 访问」，浏览器强制内部升级并拒绝用户点击「继续访问」，对抗把用户从 HTTPS 拉回 HTTP 的降级/剥离攻击。

图示

TLS 1.2 完整握手时序：

客户端                                                  服务器
  | ① ClientHello：客户端随机数 + 支持的密码套件列表 -->  |
  |   <-- ② ServerHello：服务器随机数 + 选定的套件        |
  |   <-- ③ Certificate：服务器证书链                     |
  |   <-- ④ ServerKeyExchange：ECDHE 临时公钥（附签名）   |
  | ⑤ ClientKeyExchange：客户端 ECDHE 临时公钥 -->        |
  | ⑥ 双方各自计算：预主密钥 + 两个随机数 派生 会话密钥    |
  | ⑦ Finished（已加密）-->          <-- Finished（已加密）|
  |<=============== 对称加密的应用数据 ==================>|

原理与机制

密钥如何谈成、为什么不怕被偷看。 客户端与服务器各生成一对临时 ECDHE 密钥，交换公钥后各自算出同一个共享密钥（椭圆曲线 DH 的数学性质保证第三方即使完整看到两次公钥交换也算不出来）；该共享值再与握手双方随机数一起派生出会话密钥。由于私钥从不离开本机、每次连接都用新生成的临时密钥，即使服务器长期私钥日后泄露，过去的流量也无法解密——这就是前向保密（PFS，forward secrecy）。

TLS 1.3 的简化。 1.2 完整握手需要 2-RTT 才能发送应用数据；1.3 砍掉冗余往返，把密钥协商并入握手压到 1-RTT，并在会话恢复时支持 0-RTT：客户端在第一批报文里就携带加密的早期数据。但 0-RTT 数据没有防重放保护，攻击者可以原样重发，因此只能承载幂等请求（如 GET），不能用于下单、支付类操作。

证书校验五步。 ①证书链能逐级验签到浏览器信任的根；②证书域名（SAN 字段，含通配符）与访问域名匹配；③当前时间在有效期内；④未被吊销（CRL 或 OCSP 查询）；⑤签名与哈希算法未被弃用（如 SHA-1 已淘汰）。任何一步失败，浏览器都会给出明确的证书错误页。

实例分析

抓包视角：Wireshark 抓 HTTPS 只能看到 TLS 记录层的密文与握手中的明文部分（SNI 域名、证书），看不到 HTTP 内容；Charles、mitmproxy 这类工具要「看明文」，原理是向系统安装自签根证书，再对每个站点动态签发假证书、充当中间人，与客户端和服务器各建一条 TLS 连接解密转发。本质是把你自己的根证书加进系统信任库——风险极高，只能在自用设备与授权测试范围内进行，合规边界见 kp-034 的抓包伦理讨论。

常见误区

「HTTPS = 网站可信」：TLS 只保证传输通道机密与域名身份，站点本身仍可能是钓鱼站，地址栏的锁不背书内容。
混合加密不是性能锦上添花，而是唯一可行解：纯非对称性能不可接受，纯对称无法安全分发密钥。
0-RTT 早期数据可被重放，不能承载非幂等请求。
「证书没过期」只是五项校验之一：链断裂、域名不匹配、被吊销、算法过弱都会导致浏览器报错，排查时要逐项核对。

自测题

为什么 TLS 采用混合加密，而不是全程非对称或全程对称？

答案要点： 非对称算法慢几个数量级，逐条消息加密性能不可接受；对称加密快但有密钥分发难题。折中方案：用非对称（ECDHE）只协商会话密钥，数据用对称（AES-GCM）加密。

什么是前向保密，ECDHE 如何提供它？

答案要点： 指服务器长期私钥泄露也无法解密历史流量。ECDHE 每次连接生成临时密钥对，会话密钥由临时密钥派生，长期私钥不参与会话密钥计算也不保存，历史密文随之不可恢复。

TLS 1.3 相比 1.2 的两个主要变化是什么？0-RTT 有什么风险？

答案要点： 握手压缩到 1-RTT（会话恢复支持 0-RTT），并裁剪弱算法只保留 AEAD 套件；0-RTT 早期数据无防重放保护，可被攻击者原样重发，只能放幂等请求。

列出浏览器校验证书的五个要点。

答案要点： 证书链可验证到受信任根；域名匹配（SAN，含通配符）；在有效期内；未被吊销（CRL/OCSP）；签名与哈希算法安全未被弃用。

抓包工具为什么能看到 HTTPS 明文？

答案要点： 它做中间人：向系统安装自签根证书，对目标站点动态签发假证书，与客户端、服务器各建一条 TLS 连接解密转发；前提是用户主动信任了它的根证书，仅限自用设备与授权范围。