八股文解析
HTTPS 的 TLS 握手流程是怎样的？
一句话结论
TLS 握手本质是通过非对称加密协商会话密钥，再切换对称加密传输数据，核心是 4 次往返（RTT）内的密钥协商与身份认证。
面试标准答法
1. 宏观分层：TLS 1.2 完整握手（最常考）
TLS 握手发生在 TCP 三次握手之后，总共涉及 2 次 RTT（不包括 TCP）。按阶段拆解：
阶段一：ClientHello（客户端 → 服务器）
- 客户端生成一个随机数
client_random - 携带：TLS 版本号（如 1.2）、支持的 Cipher Suites 列表（如
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256）、扩展字段（SNI、ALPN 等）
阶段二：ServerHello + 证书 + 密钥交换（服务器 → 客户端）
- 服务器返回
server_random、选定 Cipher Suite - 发送 Certificate（X.509 证书链，含公钥）
- 发送 ServerKeyExchange（若使用 ECDHE，携带椭圆曲线参数和签名）
- 发送 ServerHelloDone
阶段三：客户端密钥协商与验证（客户端 → 服务器）
- 客户端验证证书链（信任锚、有效期、吊销状态、域名匹配）
- 若使用 ECDHE：客户端生成自己的临时密钥对，计算
pre-master secret（通过 ECDH 算法） - 客户端发送 ClientKeyExchange（携带自己的公钥）
- 客户端发送 ChangeCipherSpec（通知后续加密）
- 客户端发送 Finished（用协商出的会话密钥加密的摘要）
阶段四：服务器确认（服务器 → 客户端）
- 服务器用私钥完成同样的密钥推导，发送 ChangeCipherSpec + Finished
- 此后双方用对称密钥（AES-GCM）加密应用数据
2. 密钥推导链路（必背）
master_secret = PRF(pre_master_secret, "master secret", client_random + server_random)
key_block = PRF(master_secret, "key expansion", server_random + client_random)从 key_block 中切分出 4 个密钥：
- 客户端写密钥（Client Write Key）
- 服务器写密钥（Server Write Key）
- 客户端 MAC 密钥 / IV（GCM 模式下不需要 MAC）
- 服务器 MAC 密钥 / IV
关键点：pre_master_secret 是核心机密，由 ECDHE 协商或 RSA 加密传输（TLS 1.2 仍支持 RSA 密钥交换，但已不推荐）。
3. 两种主流密钥交换对比
| 维度 | ECDHE_RSA（推荐） | RSA（已弃用） |
|---|---|---|
| 前向保密（Forward Secrecy） | ✅ 每次会话临时密钥，泄露私钥不影响历史会话 | ❌ 私钥泄露可解密所有历史流量 |
| 密钥交换方式 | ECDH 临时密钥对 + RSA 签名认证 | 客户端用服务器公钥 RSA 加密 pre-master |
| 性能 | 计算量大，但可复用会话恢复 | 计算量小，但安全风险高 |
| 浏览器兼容性 | 现代浏览器全支持 | 已禁用（Chrome 88+ 默认关闭） |
| 适用场景 | 所有现代 Web 服务 | 仅遗留系统 |
4. TLS 1.3 的差异（加分项）
| 特性 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| 握手 RTT | 2 RTT（完整） | 1 RTT（完整），0-RTT（恢复） |
| 密钥交换 | RSA / ECDHE / DHE | 仅 ECDHE（强制前向保密） |
| 密码套件 | 支持 CBC、GCM、CHACHA20 | 仅 AEAD（GCM / CHACHA20_POLY1305） |
| 握手消息 | 明文证书链 | 证书加密传输（EncryptedExtensions） |
| 会话恢复 | Session ID / Session Ticket | PSK + Ticket |
TLS 1.3 将 ServerHello 之后的握手消息全部加密，防止中间人嗅探证书和扩展信息。
常见追问
| 追问 | 要点 |
|---|---|
为什么需要 client_random 和 server_random？ | 防止重放攻击；确保每次会话的 master_secret 唯一，即使 pre-master 相同 |
| 证书链验证失败怎么办？ | 浏览器报错（NET::ERR_CERT_AUTHORITY_INVALID）；客户端可配置忽略（不安全）；企业环境可安装私有 CA |
| 什么是前向保密？为什么重要？ | 即使服务器私钥泄露，历史流量无法被解密；因为会话密钥由临时 ECDHE 密钥决定，与长期私钥无关 |
| 0-RTT 的原理和风险？ | 客户端缓存 PSK，首次请求直接携带加密数据；风险是重放攻击（replay attack），需应用层幂等设计 |
| 如何优化握手延迟？ | 会话恢复（Session Ticket）、TLS 1.3 0-RTT、HTTP/2 多路复用减少连接数、OCSP Stapling 减少证书验证往返 |
面试回答模板（30 秒版）
延伸准备
- TLS 1.3 的 0-RTT 重放防护机制：如何通过
early_data扩展 + 单次使用 Ticket + 应用层幂等来缓解重放风险。面试官深挖时能体现工程思维。
- OCSP Stapling 与证书吊销：传统 OCSP 需要客户端额外请求验证，Stapling 让服务器在握手时附带缓存的状态，减少一次 RTT。能讲清 CA 吊销机制的短板（CRL 太大、OCSP 不可用）是加分项。
- 密码套件选择策略：
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256中每段的含义——密钥交换（ECDHE）、证书签名（RSA）、对称加密（AES-128-GCM）、哈希（SHA256）。能解释为什么 GCM 是 AEAD（同时提供机密性和完整性），以及为什么 CBC 模式有 padding oracle 攻击风险。
- 性能优化实战：TLS 握手在移动端弱网下的表现——TCP 慢启动 + TLS 2 RTT 叠加，如何通过 TLS False Start（TLS 1.2 的优化）或 TLS 1.3 将延迟压缩到 1 RTT。
想系统备战大厂大模型/Agent 开发？NiceOffer 提供 SDE+LLM 双轨 1v1 陪跑，合同保底 40w 年薪，文末扫码咨询。
