课程笔记：完整的HTTPS协议通信流程
课程名称：计算机网络应用 核心摘要：本讲围绕 HTTPS 实现加密通信的核心——TLS 握手过程展开，详细剖析 ClientHello、ServerHello、证书验证、密钥协商、Finished 验证六大步骤，阐明"明文协商→非对称加密传密钥→对称加密通数据"的设计逻辑，并补充 Session 恢复（Session ID / Session Ticket）机制。
一、 核心概念与原理
- HTTPS = HTTP + TLS/SSL，在传输层之上为 HTTP 提供加密、完整性、身份认证能力。
- TLS 握手（Handshake） 是 HTTPS 通信的核心，目的是在客户端与服务端之间安全地协商出一个会话密钥（Session Key），又称对话密钥。
- 三类加密算法的分工：
- 对称加密：加解密使用同一密钥，效率高，用于握手结束后的业务数据传输。
- 非对称加密：公钥加密、私钥解密，安全性强但效率低，用于安全传递预主密钥。
- 摘要算法：如 SHA，用于校验数据完整性、生成数字签名。
- 数字证书：由 CA 机构签发，内含公钥、持有者信息、有效期、数字签名等，用于证明服务端身份。
- 会话密钥的生成：双方各自持有三个随机数，通过相同算法计算得到同一个对称密钥，整个过程密钥本身不在线传输。
二、 技术细节与协议分析
2.1 TLS 握手完整流程（以抓包访问拉勾网为例）
| 步骤 | 报文名称 | 方向 | 通信方式 | 携带内容 | 作用 |
|---|---|---|---|---|---|
| 1 | ClientHello | 客户端 → 服务端 | 明文 | TLS 版本号、客户端随机数1（Client Random）、支持的加密套件列表 | 打招呼，告知能力 |
| 2 | ServerHello | 服务端 → 客户端 | 明文 | 选定的加密套件、服务端随机数2（Server Random）、数字证书 | 确认算法、下发证书与随机数 |
| 3 | ClientKeyExchange | 客户端 → 服务端 | 非对称加密 | 用证书公钥加密的随机数3（Pre-Master Secret） | 安全传递预主密钥 |
| 4 | （服务端内部处理） | 服务端 | 非对称解密 | 用私钥解出随机数3 | 双方至此均拥有三个相同随机数 |
| 5 | （双方各自计算） | 双向 | 本地计算 | 三个随机数 + 约定算法 → 会话密钥 | 生成对称加密密钥，不传输 |
| 6 | ChangeCipherSpec + Finished | 双向 | 对称加密 | 用会话密钥加密的验证消息 | 验证双方密钥一致、握手安全 |
2.2 步骤详解
① ClientHello（客户端打招呼）
- 携带 TLS 协议版本号。
- 携带客户端生成的随机数1：用于后续会话密钥的生成。
- 携带 Cipher Suites（加密套件列表）：浏览器本地支持的套件，本例中抓到 16 组。
- 每一组套件由 三部分 组成：对称加密算法 + 非对称加密算法 + 摘要算法。
- 示例：
RSA+AES+SHA，不同长度组合形成多组。 - 末尾括号中的十六进制（如
0xC02F）为该组套件的编号。
- 可附带 Session 信息（如之前会话未完全释放）。
② ServerHello（服务端回应）
- 从客户端的 16 组套件中选定一组（如编号
0xC02F）。 - 生成并发送服务端随机数2。
- 下发数字证书（本例证书长度 2809 字节，包含 Subject Public Key Info 即公钥信息）。
③ 客户端验证证书 + 生成随机数3
- 验证流程：
- 证书链（信任链）逐级校验：浏览器/操作系统内置 CA 根证书及中间证书，逐级向上验证。
- 签名解密：用内置 CA 公钥解密证书签名，比对摘要，确认未被篡改。
- 有效期校验：是否在有效期内。
- 域名匹配：证书登记的域名与访问的目标主机（host）是否一致，防止劫持/钓鱼。
- 验证通过后，客户端生成随机数3（Pre-Master Secret）。
- 用证书中的公钥加密随机数3，发送给服务端（非对称加密，密文传输）。
④ 服务端解密
- 服务端用自身私钥解密，获得随机数3（Pre-Master Secret）。
- 至此，客户端与服务端均拥有三个相同的随机数：
- 随机数1（Client Random，明文）
- 随机数2（Server Random，明文）
- 随机数3（Pre-Master Secret，非对称加密传输）
⑤ 会话密钥生成
- 双方使用相同的特定算法，将三个随机数计算为会话密钥（Session Key）。
- 该密钥用于后续对称加密通信。
- 关键点：密钥本地生成、不在线传输，双方独立计算但结果一致。
⑥ Finished 验证
- 双方第一次使用会话密钥加密一条消息发送给对方。
- 若对方能成功解密，证明三方随机数与算法一致，会话密钥相同，握手过程安全。
- 验证通过后，后续所有 Application Data 均使用会话密钥进行对称加密传输（抓包看到的是密文，无法直接读懂）。
2.3 通信方式演进
明文（协商能力、交换随机数1/2、下发证书）
↓
非对称加密（公钥加密随机数3/Pre-Master Secret）
↓
本地计算（三个随机数 → 会话密钥）
↓
对称加密（会话密钥加密业务数据 + Finished 验证）
2.4 Session 恢复机制
当浏览器异常关闭或网页崩溃后重新访问，为避免完整 TLS 握手带来的开销，有两种恢复方案：
| 机制 | 原理 | 优点 | 缺点/限制 | 浏览器支持 |
|---|---|---|---|---|
| Session ID | 每个 Session 有唯一编号，重连时携带该编号，服务端若有记录则复用已协商的会话密钥 | 实现简单 | Session ID 仅保存在单台服务器，集群环境下请求落到其他节点则失效，需重新握手 | 所有浏览器均支持 |
| Session Ticket | 不发送 Session ID，而是发送上次会话中服务端下发的加密 Session Ticket（内含会话密钥与加密套件）；服务端用私钥解密成功即可复用 | 不依赖服务端内存状态，适配集群 | 协议较新 | 仅 Firefox、Chrome 支持 |
三、 实践应用与配置命令
本节主要通过 抓包工具（如 Wireshark） 分析访问 拉勾网 时的 TLS 握手包，关键过滤与查看点：
# Wireshark 过滤 TLS 握手报文
tls.handshake.type == 1 # ClientHello
tls.handshake.type == 2 # ServerHello
tls.handshake.type == 11 # Certificate
tls.handshake.type == 16 # ClientKeyExchange
# 关注字段
# - TLS 版本号：tls.handshake.version
# - 客户端随机数：tls.handshake.random
# - 加密套件列表：tls.handshake.ciphersuites
# - 选定套件编号：tls.handshake.ciphersuite（如 0xC02F）
# - 证书公钥信息：certificate.subject_public_key_info
抓包步骤提示：先关闭浏览器再重新打开并访问目标站点，可观察完整握手流程；具体包数取决于服务端是否对 HTTPS 做了优化，但大体步骤一致。
四、 重点与难点提示
- 三个随机数的作用：Client Random、Server Random、Pre-Master Secret 共同生成会话密钥；第三个随机数用非对称加密传输，是安全性的关键。
- 会话密钥不传输：双方各自本地计算，仅交换随机数，这是 TLS 设计的精髓。
- 对称 vs 非对称：握手用非对称（安全传密钥），通信用对称（效率高）。
- 证书验证四要素：① 证书链逐级校验 ② 签名可解密且摘要一致（防篡改）③ 有效期 ④ 域名匹配（防钓鱼）。
- Finished 消息的意义：验证会话密钥一致性，确保握手过程未被中间人篡改。
- Session ID vs Session Ticket：核心区别在于状态是否保存在服务端，集群环境下优先考虑 Session Ticket。
- 面试要点：能清晰说出六大步骤、三种加密算法的分工、为何最终用对称加密即可。
五、 课后疑问/遗留问题
- 会话密钥生成的"特定算法"具体是什么？（课程未展开，后续可结合 RFC 5246 / TLS 1.2 PRF 深入学习）
- TLS 1.3 相较 TLS 1.2 在握手流程上有何简化（如 1-RTT / 0-RTT）？
- Session Ticket 的加密密钥如何在服务端集群间安全轮换与管理？
- 双向 TLS（mTLS）认证流程与本讲单向认证的差异是什么？