1. HTTPS 握手的目标
HTTPS 握手是 TLS（Transport Layer Security）协议的核心部分，主要实现以下目标：
- 身份验证：确保客户端连接的是真实的服务器（而非中间人）。
- 密钥交换：安全协商出一个对称密钥（用于加密通信数据）。
- 加密通信：使用对称密钥加密后续的 HTTP 请求和响应。
2. HTTPS 握手详细流程
阶段1：Client Hello
-
客户端发起请求
客户端（如浏览器）向服务器发送Client Hello消息，包含以下信息：- TLS 版本：客户端支持的 TLS 版本（如 TLS 1.2、TLS 1.3）。
- 随机数 A（Client Random） ：32 字节的随机数，用于后续生成主密钥。
- 加密套件列表：客户端支持的加密算法组合（如
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256）。 - 会话 ID：用于恢复之前的会话（可选）。
- 扩展字段：如 SNI（Server Name Indication，用于指定访问的域名）。
阶段2：Server Hello
-
服务器响应
服务器收到Client Hello后，回复Server Hello消息，包含以下信息：- TLS 版本：双方协商后的 TLS 版本（如 TLS 1.2）。
- 随机数 B（Server Random） ：32 字节的随机数，用于后续生成主密钥。
- 加密套件：从客户端支持的列表中选择一个（如
TLS_RSA_WITH_AES_128_GCM_SHA256）。 - 会话 ID：用于恢复会话（若支持会话恢复）。
阶段3：服务器证书
-
发送证书
服务器发送自己的数字证书（包含公钥），证书内容如下：- 公钥：用于加密
Pre-Master Secret。 - 域名：证书绑定的域名（如
*.example.com）。 - 颁发者：签发证书的 CA（如
DigiCert）。 - 有效期：证书的起止时间。
- 签名：CA 对证书内容的数字签名。
- 公钥：用于加密
-
可选：证书链
服务器可能还会发送中间 CA 证书，帮助客户端构建完整的证书链。
阶段4：客户端验证证书
-
验证证书合法性
客户端收到证书后，进行以下检查：- 证书链验证：从服务器证书到根 CA 证书的完整链是否可信。
- 域名匹配：证书中的域名是否与访问的域名一致，防止中间人攻击。
- 有效期检查：确保证书未过期。
- 吊销状态检查：通过 OCSP 或 CRL 检查证书是否被吊销。
-
验证失败
若证书验证失败（如域名不匹配或证书过期），客户端会终止连接并提示错误（如浏览器显示NET::ERR_CERT_INVALID）。
阶段5：密钥交换
- 生成 Pre-Master Secret
客户端生成一个 48 字节的随机数 C（称为Pre-Master Secret），这是后续生成主密钥的关键材料。 - 加密 Pre-Master Secret
客户端使用服务器证书中的公钥加密Pre-Master Secret，并将加密后的结果发送给服务器。 - 服务器解密 Pre-Master Secret
服务器使用自己的私钥解密，得到Pre-Master Secret。
阶段6：生成主密钥
-
第一次 PRF：生成 Master Secret
客户端和服务器分别使用以下参数，通过伪随机函数（PRF）生成相同的Master Secret：- 随机数 A（Client Random）
- 随机数 B（Server Random）
- Pre-Master Secret
公式：
复制
Master Secret = PRF(Pre-Master Secret, "master secret", Client Random + Server Random) -
第二次 PRF：派生会话密钥
从Master Secret派生出实际的会话密钥（如对称加密密钥、MAC 密钥、IV 等）。
公式：复制
key_block = PRF(Master Secret, "key expansion", Server Random + Client Random)
阶段7：完成握手
- 客户端发送 Finished 消息
客户端使用生成的对称密钥加密一段验证数据（包含之前所有握手消息的哈希），发送给服务器。 - 服务器发送 Finished 消息
服务器同样使用对称密钥加密一段验证数据，发送给客户端。 - 验证 Finished 消息
双方解密并验证对方发送的 Finished 消息，确保握手过程未被篡改。
阶段8：加密通信
- 对称加密通信
握手完成后，客户端和服务器使用协商好的对称密钥（如 AES-GCM）加密后续的 HTTP 请求和响应。
3. 加密套件：定制化的流水线
加密套件就像一条流水线，定义了 HTTPS 握手和通信过程中每个环节使用的算法。以下是流水线的每个环节及其对应的算法：
流水线环节与算法
| 环节 | 算法类型 | 具体算法示例 | 作用 |
|---|---|---|---|
| 密钥交换 | 密钥交换算法 | ECDHE、RSA、DHE | 安全交换密钥材料（如 Pre-Master Secret）。 |
| 身份验证 | 身份验证算法 | RSA、ECDSA | 验证服务器身份（防止中间人攻击）。 |
| 对称加密 | 对称加密算法 | AES-128-GCM、ChaCha20 | 加密通信数据（高效且安全）。 |
| 完整性校验 | 完整性校验算法 | HMAC-SHA256、Poly1305 | 验证数据完整性（防止篡改）。 |
流水线示例
假设加密套件是 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，以下是流水线的每个环节：
-
密钥交换
- 算法：ECDHE
- 作用：客户端和服务器使用 ECDHE 算法交换密钥材料，生成 Pre-Master Secret。
-
身份验证
- 算法：RSA
- 作用：服务器使用 RSA 私钥对握手消息签名，客户端使用服务器的 RSA 公钥验证签名。
-
对称加密
- 算法：AES-128-GCM
- 作用：客户端和服务器使用 AES-128-GCM 算法加密通信数据。
-
完整性校验
- 算法：HMAC-SHA256
- 作用：客户端和服务器使用 HMAC-SHA256 算法验证数据的完整性。
4. 流程图
以下是 HTTPS 握手的流程图，结合了加密套件的流水线环节：
plaintext
复制
+-------------------+ +-------------------+ +-------------------+
| Client Hello | ----> | Server Hello | ----> | Server Certificate
+-------------------+ +-------------------+ +-------------------+
| | |
| | |
v v v
+-------------------+ +-------------------+ +-------------------+
| Key Exchange | <---- | Key Exchange | <---- | Key Exchange |
| (ECDHE) | | (ECDHE) | | (ECDHE) |
+-------------------+ +-------------------+ +-------------------+
| | |
| | |
v v v
+-------------------+ +-------------------+ +-------------------+
| Authentication | <---- | Authentication | <---- | Authentication |
| (RSA) | | (RSA) | | (RSA) |
+-------------------+ +-------------------+ +-------------------+
| | |
| | |
v v v
+-------------------+ +-------------------+ +-------------------+
| Symmetric Enc. | <---- | Symmetric Enc. | <---- | Symmetric Enc. |
| (AES-128-GCM) | | (AES-128-GCM) | | (AES-128-GCM) |
+-------------------+ +-------------------+ +-------------------+
| | |
| | |
v v v
+-------------------+ +-------------------+ +-------------------+
| Integrity Check | <---- | Integrity Check | <---- | Integrity Check |
| (HMAC-SHA256) | | (HMAC-SHA256) | | (HMAC-SHA256) |
+-------------------+ +-------------------+ +-------------------+
