11. HTTPS 握手与混合加密（热度 451 / 336 · 高频选考）
Q： HTTPS 的握手过程？为什么用混合加密？
A：
握手过程（以 TLS 1.2 为主，能提 1.3 更好）
diagram
Client Server
|--- ClientHello ------------------>| 版本、密码套件、客户端随机数、SNI
| | 扩展（ALPN、supported_versions…）
|<-- ServerHello + Certificate -----| 选定套件、服务器随机数、证书（含公钥）
|<-- ServerKeyExchange (ECDHE) -----|
|<-- ServerHelloDone ----------------|
| [客户端校验证书链] |
|--- ClientKeyExchange ------------>| RSA：用服务器公钥加密 pre-master
| | ECDHE：双方各自算出共享密钥
|--- ChangeCipherSpec + Finished -->|
|<-- ChangeCipherSpec + Finished ---|
| 此后应用数据走对称加密（AES-GCM等）|- Client Hello： TLS 版本、加密套件列表、客户端随机数、扩展（SNI、ALPN：TCP 上的 TLS 只会是
h2/http/1.1，h3出现在 QUIC 自带的 TLS 握手里）。 - Server Hello + 证书： 选定套件，返回服务器随机数与数字证书（含公钥，可能附中间证书）。
- 证书校验： 客户端验证证书链、有效期、域名（CN/SAN）、吊销状态（见第 12 题）。
- 密钥交换： RSA 套件——客户端生成 pre-master secret，用服务器公钥加密发送；ECDHE——双方交换 DH/ECC 参数各自算出共享密钥（前向安全）。
- 生成会话密钥： 用「客户端随机数 + 服务器随机数 + pre-master」经 PRF 推导对称密钥。随机数用于防重放并保证会话密钥唯一。
- Finished： 双方用会话密钥加密握手摘要校验；此后应用数据走对称加密（如 AES-GCM）。
TLS 1.3 要点（加分）
- 握手压缩到 1-RTT（会话恢复可 0-RTT，但 0-RTT 有重放风险，仅幂等请求适用）。
- 废弃 RSA 密钥交换，强制前向安全（ECDHE）。
- 加密握手后半段：证书等也加密，减少明文元数据暴露。
- 套件大幅精简（AEAD only：AES-GCM、ChaCha20-Poly1305 等）。
为什么混合加密？
| 机制 | 作用 | 原因 |
|---|---|---|
| 非对称加密 / 密钥协商（RSA 加密 pre-master；ECDHE 做 DH 协商） | 安全交换密钥、身份认证 | 安全但性能差（慢几个数量级），不适合加密整段流量。注意 ECDHE 本身不加密业务数据，它是密钥协商算法（DH 的椭圆曲线 ephemeral 变体），只提供前向安全；能"加密"的非对称算法是 RSA |
| 对称加密（AES-GCM 等） | 加密应用数据 | 性能好，可硬件加速（AES-NI） |
| 哈希/签名（SHA-256 等） | 完整性、证书签名 | 防篡改、防冒充 |
设计动机：让昂贵的非对称只做「一次性的密钥协商与认证」，让便宜的对称扛「持续的数据传输」——兼顾安全与性能。
常见追问
追问 1：HTTPS 为什么中间还要随机数？只靠证书公钥不行吗？
- 答题要点： 若只用固定公钥加密，相同明文可能得到相同密文，且易被重放。引入客户端/服务器随机数使每次会话密钥不同；再配合 Finished 校验，双方确认握手未被篡改。
追问 2：TLS 1.3 相比 1.2 快在哪里？安全增强是什么？
- 答题要点： 1-RTT/0-RTT 减少往返；握手消息加密；去掉 RSA 密钥交换等不安全选项，强制 PFS。注意 0-RTT 数据可被重放，只应用于安全的幂等请求。
追问 3：证书校验通过了，还会不会被中间人？
- 答题要点： 可能。前提是用户信任了恶意根证书（企业中间人代理、恶意 CA、被入侵的信任库），或客户端未真正校验证书（
verify=False）。防御：严格校验链、HSTS、证书透明（CT）、可选 Certificate Pinning。
易错点
| 易错说法 | 纠正 |
|---|---|
| 「HTTPS 全程非对称加密」 | 只有握手/密钥协商用非对称；数据用对称 |
| 「TLS 在 DNS 之前」 | 先 DNS → TCP → TLS |
| 「证书里有服务器私钥」 | 证书含公钥；私钥仅服务器持有 |
| 「会话密钥用服务器公钥加密传输=唯一方式」 | RSA 套件是这样；ECDHE 是双方各算共享密钥 |
| 「TLS 1.3 仍 2-RTT」 | 默认 1-RTT，恢复可 0-RTT |
与选择题对照
- 主库 150： 第 90 题（https 访问流程）、第 91 题（HTTPS 端口与组成）、第 99 题（对称/非对称）、第 100 题（非对称算法）、第 113 题（对称 vs 非对称性能）、第 114 题（SSL/TLS 工作层）、第 115 题（TLS 握手目的）、第 124 题（协议顺序）。
- 补题 16： 无直接 TLS 选择题；应用层对照见补-14（邮件协议常用 TLS 加密端口）。
- 口述联动： 选择题考「混合加密原因/工作层」；面试要完整报文级时序 + 1.3 差异 + 前向安全。
工程 / 抓包背景
- openssl：bash
openssl s_client -connect example.com:443 -servername example.com -tls1_2 openssl s_client -connect example.com:443 -servername example.com -tls1_3 openssl x509 -in cert.pem -noout -text - Wireshark： ClientHello/ServerHello；
tls.handshake.extensions_alpn_str == "h2"；SSLKEYLOGFILE 可解密应用数据。 - curl：
curl -v https://example.com看 TLS 版本、证书主体、ALPN。 - Nginx：
ssl_protocols TLSv1.2 TLSv1.3;、ssl_certificate/ssl_certificate_key、ssl_session_cache。 - 浏览器： 安全标识、证书链、Connection 是否
h2/http/1.1。