HTTPS 的核心是 "HTTP + TLS/SSL" ，其中 TLS（Transport Layer Security，传输层安全）是保障通信安全的核心协议（SSL 是其前身，已被淘汰）。TLS 的核心目标是：在不安全的网络（如互联网）中，为客户端和服务器建立加密、认证、防篡改的通信通道。
本文将从 TLS 完整握手流程（以 TLS 1.3 为主，兼容 TLS 1.2 差异）、数字证书的结构与作用、数字签名的原理与验证 三个维度，进行底层细节拆解，兼顾理论与工程实现逻辑。
一、TLS 协议核心目标与核心技术
在讲解流程前，先明确 TLS 要解决的核心问题及依赖的关键技术：
1.1 核心目标（CIA 三元组）
- 机密性（Confidentiality）：通信内容仅对客户端和服务器可见，中间攻击者无法窃取（依赖对称加密、非对称加密）。
- 完整性（Integrity）：通信内容在传输过程中未被篡改（依赖哈希函数、数字签名）。
- 认证性（Authenticity）：确认对方是真实的通信对象（而非中间人伪装，依赖数字证书、数字签名）。
1.2 核心技术栈
| 技术类型 | 作用 | 代表算法 |
|---|---|---|
| 非对称加密 | 密钥交换、数字签名 | RSA、ECDH（椭圆曲线 Diffie-Hellman）、ECDSA |
| 对称加密 | 加密通信数据（效率高） | AES-GCM、ChaCha20-Poly1305 |
| 哈希函数 | 生成数据摘要（防篡改、签名基础） | SHA-256、SHA-384 |
| 数字证书 | 绑定服务器身份与公钥（解决"公钥信任"） | X.509 标准 |
| 数字签名 | 验证数据来源合法性、防篡改 | RSA-SHA256、ECDSA-SHA384 |
1.3 关键概念铺垫
- 对称加密：加密和解密用同一把密钥（如 AES），速度快，但密钥协商过程需保障安全（不能明文传输）。
- 非对称加密：有公钥（公开）和私钥（保密），公钥加密的内容仅私钥可解，私钥签名的内容仅公钥可验（如 RSA），速度慢，适合小数据传输（如密钥交换）。
- 密钥交换：TLS 握手的核心是"安全协商出一把临时对称密钥"，后续通信均用该密钥加密（对称加密效率高）。
- 会话复用：避免每次连接都完整握手（耗时），通过会话票据（Session Ticket）或会话 ID 复用已协商的密钥。
二、TLS 完整握手流程（TLS 1.3 详解，对比 TLS 1.2）
TLS 握手是 HTTPS 建立连接的核心阶段，TLS 1.3 是目前最新、最安全、最高效的版本（2018 发布），相比 TLS 1.2 大幅简化流程、缩短延迟。以下分步骤拆解 TLS 1.3 标准握手流程（无会话复用场景），并标注与 TLS 1.2 的关键差异。
整体流程概览
TLS 1.3 握手仅需 1 个 RTT（往返时间）（客户端 → 服务器 → 客户端）即可完成，而 TLS 1.2 需 2 个 RTT，核心优化是"将密钥交换和认证并行处理"。
完整流程分为 4 个关键步骤：
- 客户端问候（Client Hello）：客户端发起连接，提供支持的协议版本、加密套件、随机数等。
- 服务器问候 + 证书 + 密钥交换 + 完成（Server Hello + Certificate + Certificate Verify + Finished）：服务器回应，认证身份，协商密钥。
- 客户端验证 + 完成（Client Finished）：客户端验证服务器身份，确认密钥，握手完成。
- 应用数据传输：用协商的对称密钥加密 HTTP 数据。
步骤拆解（带数据包细节）
1. 第一步：客户端发送 Client Hello（客户端 → 服务器）
客户端发起连接时，发送第一个数据包，核心目的是"告知服务器自己的能力，提供密钥交换的初始材料"。
数据包包含核心字段：
- TLS 版本：客户端支持的最高版本（如 TLS 1.3）。
- 随机数（Client Random）：32 字节随机数（由客户端生成，用于后续密钥计算，非对称加密无法破解）。
- 加密套件列表（Cipher Suites） ：客户端支持的加密套件（按优先级排序），格式为"密钥交换算法-对称加密算法-哈希算法"，例如：
TLS_AES_256_GCM_SHA384：ECDH 密钥交换 + AES-256-GCM 对称加密 + SHA-384 哈希。TLS_CHACHA20_POLY1305_SHA256：适合低功耗设备（如手机）。
- 扩展字段（Extensions） ：
supported_groups：支持的椭圆曲线（如 secp256r1、x25519，用于 ECDH 密钥交换）。key_share：客户端的 ECDH 公钥（客户端生成椭圆曲线密钥对，发送公钥给服务器，私钥自己保留）。signature_algorithms：支持的数字签名算法（如 ECDSA-SHA384，用于验证服务器证书签名）。server_name：SNI（服务器名称指示），告知服务器要访问的域名（如www.baidu.com），支持一台服务器部署多个 HTTPS 站点（共享 IP）。
TLS 1.2 差异：
- TLS 1.2 无
key_share扩展，客户端仅发送支持的密钥交换算法（如 RSA、ECDH），不携带公钥，需后续额外步骤交换密钥（导致多 1 个 RTT）。 - TLS 1.2 加密套件包含密钥交换算法（如
TLS_RSA_WITH_AES_256_CBC_SHA256），而 TLS 1.3 密钥交换算法统一为 ECDH（简化设计）。
2. 第二步：服务器发送 Server Hello + 证书 + 密钥交换 + 完成（服务器 → 客户端）
服务器收到 Client Hello 后，综合自身配置（如支持的 TLS 版本、加密套件）回应，核心目的是"确认通信参数、认证自己的身份、完成密钥交换"。这一步是 TLS 握手的核心，包含 4 个关键子消息（打包在一个 TCP 数据包中）：
（1）Server Hello（确认通信参数）
- 选择双方都支持的 最高 TLS 版本（如 TLS 1.3）。
- 选择双方都支持的 加密套件 （如
TLS_AES_256_GCM_SHA384）。 - 服务器随机数（Server Random）：32 字节随机数（服务器生成，与 Client Random 共同用于密钥计算）。
- 扩展字段：确认
key_share（服务器的 ECDH 公钥）、server_name等。
（2）Certificate（发送数字证书，认证身份）
服务器发送自己的 X.509 数字证书（可能是证书链，包含服务器证书、中间 CA 证书），核心目的是"证明自己是域名的合法所有者，同时提供公钥"。
证书的详细结构见下文"三、数字证书深度解析"，此处重点说明：客户端通过验证证书的有效性，确认"服务器的公钥是可信的"（避免中间人替换公钥）。
（3）Certificate Verify（数字签名，验证证书私钥所有权）
服务器用自己证书对应的 私钥，对"握手过程中的关键数据（如 Client Random、Server Random、密钥交换材料）"进行数字签名，发送给客户端。
客户端收到后，用证书中的 公钥 验证该签名：
- 若验证通过：证明服务器确实拥有证书对应的私钥（即"服务器是证书的合法持有者"，排除中间人伪造证书的可能）。
- 若验证失败：握手终止，通信中断。
TLS 1.2 差异：TLS 1.2 中，若密钥交换算法为 RSA（即"RSA 密钥交换"），则服务器会用私钥加密"预主密钥（Pre-Master Secret）"，无需 Certificate Verify 消息；而 TLS 1.3 强制使用 ECDH 密钥交换，必须通过 Certificate Verify 验证私钥所有权。
（4）Finished（验证密钥协商完整性）
服务器用"已协商的对称密钥"加密"握手过程的所有消息摘要"，发送给客户端。客户端收到后，用同样的密钥解密，对比摘要是否一致：
- 一致：说明密钥协商过程未被篡改，密钥是安全的。
- 不一致：说明握手被中间人篡改，终止通信。
3. 第三步：客户端发送 Client Finished（客户端 → 服务器）
客户端完成以下操作后，发送 Finished 消息，标志握手完成：
- 验证服务器证书：检查证书是否过期、是否被吊销、域名是否匹配、证书链是否可信（根 CA 证书在客户端信任列表中）。
- 验证 Certificate Verify 签名：用证书公钥验证服务器的数字签名，确认服务器身份合法。
- 计算对称密钥 ：通过 Client Random、Server Random、ECDH 密钥交换的"共享密钥"，结合哈希函数，生成最终的 会话密钥（Session Key） （TLS 1.3 中称为"Traffic Key"）。
- 密钥计算逻辑：
Session Key = HKDF(ECDH 共享密钥, Client Random + Server Random, 哈希算法)（HKDF 是密钥派生函数，避免直接使用原始共享密钥）。
- 密钥计算逻辑：
- 发送 Finished 消息：用会话密钥加密"握手消息摘要"，发送给服务器。服务器收到后解密验证，确认客户端已正确获取会话密钥。
4. 第四步：应用数据传输（双向加密）
握手完成后，客户端和服务器均持有相同的会话密钥，后续所有 HTTP 数据（请求行、请求头、请求体，响应行、响应头、响应体）均通过以下方式传输：
- 加密：用对称加密算法（如 AES-GCM）加密 HTTP 数据。
- 完整性校验：用哈希函数（如 SHA-256）生成数据摘要，与加密数据一起发送（AES-GCM 是"认证加密算法"，内置完整性校验，无需额外步骤）。
TLS 1.2 差异：TLS 1.2 支持非认证加密算法（如 AES-CBC），需额外用 HMAC 进行完整性校验，而 TLS 1.3 仅支持认证加密算法（更安全）。
会话复用流程（优化延迟）
为避免每次连接都进行完整握手（1 个 RTT 延迟），TLS 1.3 支持 会话票据（Session Ticket） 复用：
- 第一次握手完成后，服务器生成一个"会话票据"（包含过期时间、复用的会话密钥等，用服务器的长期密钥加密），发送给客户端。
- 客户端下次连接时，在 Client Hello 中携带该会话票据。
- 服务器验证票据有效后，直接跳过证书验证、密钥交换步骤，用票据中的会话密钥加密通信，握手仅需 0 个 RTT（即时传输应用数据）。
三、数字证书深度解析（X.509 标准）
数字证书是 TLS 认证的核心，本质是"由权威第三方（CA，Certificate Authority）签名的身份凭证"，解决了"公钥信任问题"------客户端如何确认"服务器提供的公钥是真实的，而非中间人伪造的"。
3.1 核心作用
- 绑定身份与公钥 ：证明"某个域名（如
www.taobao.com）的合法所有者，对应的公钥是 XXXX"。 - 提供信任链：通过 CA 的签名，将服务器身份的信任转移到 CA（客户端预装了根 CA 证书，默认信任根 CA）。
- 防篡改：证书内容被 CA 签名，中间人无法修改证书中的公钥、域名等信息（修改后签名会失效）。
3.2 X.509 证书结构（ASN.1 编码）
X.509 是数字证书的国际标准，所有 HTTPS 证书均遵循此标准，其核心字段（简化后）如下：
| 字段名称 | 作用说明 |
|---|---|
| Version（版本） | X.509 v3（目前主流版本，支持扩展字段） |
| Serial Number（序列号） | CA 分配给证书的唯一标识（用于吊销证书） |
| Signature Algorithm（签名算法） | CA 签署证书所用的算法（如 ECDSA-SHA256、RSA-SHA384） |
| Issuer（签发者） | 签发证书的 CA 信息（如"Let's Encrypt Authority X3"），包含 CA 名称、公钥标识 |
| Validity（有效期） | 证书的有效时间（Not Before：生效时间；Not After：过期时间） |
| Subject（主体） | 证书所有者信息（HTTPS 场景下，核心是 Common Name 或 Subject Alternative Name（SAN），即域名） |
| Subject Public Key Info（主体公钥信息） | 证书所有者的公钥 + 公钥算法（如 ECDH 公钥 + 椭圆曲线参数） |
| Extensions（扩展字段） | 关键扩展（TLS 必须）： |
| - Subject Alternative Name（SAN） | 支持多个域名（如 www.baidu.com、baidu.com），替代老旧的 Common Name |
| - Key Usage（密钥用途） | 限制公钥用途（如"仅用于 TLS 服务器认证"） |
| - Authority Information Access（AIA） | 指向 CA 的证书吊销列表（CRL）或在线证书状态协议（OCSP）地址，用于验证证书是否被吊销 |
| Signature（签名） | CA 用自己的私钥，对"证书除签名外的所有字段"计算的数字签名（验证证书完整性和合法性） |
3.3 证书链（信任链）
服务器发送的证书通常是"证书链"（而非单张证书），原因是：客户端仅预装"根 CA 证书"（如 VeriSign、Let's Encrypt 根 CA），而服务器证书是由"中间 CA"签发的（根 CA 不直接签发服务器证书，避免根私钥泄露）。
证书链结构示例（从服务器到根 CA）：
服务器证书（www.baidu.com）→ 中间 CA 证书（DigiCert Global CA G2）→ 根 CA 证书（DigiCert Global Root CA）客户端验证证书链的流程：
- 验证服务器证书的签名：用中间 CA 证书的公钥解密服务器证书的签名，对比证书内容的摘要，确认服务器证书未被篡改。
- 验证中间 CA 证书的签名：用根 CA 证书的公钥解密中间 CA 证书的签名，确认中间 CA 证书合法。
- 验证根 CA 证书：根 CA 证书是"自签名证书"（用自己的私钥签名），且已预装在客户端（操作系统或浏览器信任列表中），直接信任。
3.4 证书吊销机制（避免过期/泄露证书被滥用）
若证书的私钥泄露、域名变更，CA 会将该证书"吊销"，客户端需验证证书是否已吊销，主要通过两种方式：
- CRL（Certificate Revocation List，证书吊销列表） ：CA 定期发布包含所有吊销证书序列号的列表，客户端下载后查询服务器证书序列号是否在列表中。
- 缺点：列表体积大，更新不及时。
- OCSP（Online Certificate Status Protocol，在线证书状态协议） ：客户端向 CA 的 OCSP 服务器发送证书序列号，实时查询证书状态。
- 优化：TLS 1.3 支持 OCSP Stapling（OCSP 装订），服务器提前向 OCSP 服务器查询自己的证书状态，将结果绑定在证书中发送给客户端，避免客户端额外请求 OCSP 服务器（减少延迟）。
四、数字签名深度解析（原理 + 验证流程）
数字签名是"非对称加密的逆向应用"，核心作用是 "验证数据来源的合法性 + 数据完整性"，在 TLS 中用于两个关键场景：
- CA 对数字证书的签名（验证证书合法）。
- 服务器对 Certificate Verify 消息的签名（验证服务器拥有证书私钥）。
4.1 核心原理
数字签名基于"私钥签名，公钥验证"的逻辑，结合哈希函数（避免直接对大数据加密，提高效率），流程如下：
签名流程（签名者：CA 或服务器）
- 生成数据摘要：对需要签名的原始数据（如证书内容、握手消息），用哈希函数（如 SHA-256）计算摘要（固定长度，不可逆，数据微小变化会导致摘要完全不同）。
- 私钥加密摘要：用签名者的私钥（CA 的私钥、服务器的私钥）对摘要进行加密，生成"数字签名"。
验证流程（验证者：客户端）
- 生成数据摘要：对收到的原始数据（如证书、握手消息），用相同的哈希函数计算摘要。
- 公钥解密签名：用签名者的公钥（CA 证书的公钥、服务器证书的公钥）对收到的数字签名进行解密，得到"原始摘要"。
- 对比摘要 ：将自己计算的摘要与解密得到的原始摘要对比：
- 一致：数据未被篡改，且确实是签名者发送的（只有签名者的私钥能生成该签名）。
- 不一致：数据被篡改，或签名者身份伪造（中间人用自己的私钥签名）。
4.2 数学过程（以 RSA 签名为例）
RSA 签名是最常用的签名算法，基于大整数分解的数学难题，步骤如下：
前提（RSA 密钥对）
- 私钥：
(d, n)（d 是私有指数，n 是大整数，由两个大质数相乘得到）。 - 公钥：
(e, n)（e 是公开指数，通常取 65537，n 与私钥相同）。
签名流程（服务器/CA 侧）
- 对原始数据 M 计算哈希摘要：
H = SHA-256(M)（H 是 32 字节固定长度）。 - 对摘要 H 进行"填充"（如 PKCS#1 v1.5 或 PSS 填充，避免安全漏洞），得到 H'。
- 用私钥加密 H'：
Signature = H'^d mod n（RSA 加密本质是模幂运算）。
验证流程（客户端侧）
- 对收到的原始数据 M 计算哈希摘要：
H = SHA-256(M)。 - 用公钥解密签名：
H' = Signature^e mod n。 - 对 H' 进行"去填充"，得到 H_verify。
- 对比 H 与 H_verify：一致则验证通过。
4.3 椭圆曲线签名（ECDSA，TLS 1.3 推荐）
ECDSA（Elliptic Curve Digital Signature Algorithm）是基于椭圆曲线数学的签名算法，相比 RSA 具有以下优势：
- 密钥长度短（256 位 ECDSA 安全性 ≈ 2048 位 RSA），传输和计算效率更高。
- 签名体积小（64 字节 vs RSA 256 字节），减少 TLS 握手数据包大小。
ECDSA 签名流程（简化）：
- 签名者生成临时椭圆曲线密钥对（k, Q）。
- 对原始数据 M 计算哈希摘要 H = SHA-256(M)。
- 基于椭圆曲线运算生成签名（r, s）：
r = x 坐标 mod n（x 是 Q 的 x 坐标），s = (H + r*d)/k mod n（d 是签名者私钥）。 - 验证者用签名者公钥（椭圆曲线上的点）、H、(r, s) 进行椭圆曲线运算，验证是否满足
r = x' mod n（x' 是运算结果的 x 坐标）。
4.4 数字签名 vs 加密（核心区别）
| 维度 | 数字签名 | 加密 |
|---|---|---|
| 核心目的 | 认证身份 + 防篡改 | 机密性（隐藏数据） |
| 密钥使用 | 私钥签名，公钥验证 | 公钥加密，私钥解密（非对称）；同一密钥（对称） |
| 数据流向 | 原始数据公开，签名附加在数据后 | 原始数据隐藏，加密后的数据传输 |
| TLS 中的应用 | 证书签名、Certificate Verify 消息 | 密钥交换（RSA 密钥交换）、数据传输（对称加密） |
五、TLS 1.2 与 TLS 1.3 核心差异总结
| 特性 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| 握手 RTT | 2 个（Client Hello → Server Hello → Client Finished） | 1 个（Client Hello → Server 响应 → 应用数据） |
| 密钥交换算法 | 支持 RSA、ECDH、DHE 等 | 仅支持 ECDH（强制前向安全） |
| 加密套件 | 支持非认证加密（如 AES-CBC） | 仅支持认证加密（AES-GCM、ChaCha20） |
| 会话复用 | 支持会话 ID、会话票据 | 仅支持会话票据（0-RTT 复用） |
| 证书验证 | 可选（RSA 密钥交换时无需） | 强制（Certificate Verify 消息） |
| 安全性 | 存在降级攻击风险（如 POODLE） | 修复所有已知漏洞，禁用不安全算法 |
| 握手速度 | 较慢（多 1 个 RTT） | 较快（适合移动网络、低延迟场景） |
六、常见问题与安全风险
6.1 中间人攻击（MITM）为何失效？
中间人攻击的核心是"拦截并篡改客户端与服务器的通信"，但 TLS 通过以下机制防御：
- 服务器证书由 CA 签名，中间人无法伪造 CA 签名（没有 CA 私钥）。
- 密钥交换基于 ECDH（前向安全），中间人即使拦截了公钥，也无法计算出共享密钥（椭圆曲线离散对数问题不可解）。
- Finished 消息验证握手消息摘要，中间人篡改任何消息都会导致摘要不一致。
6.2 前向安全（Forward Secrecy）
TLS 1.3 强制支持前向安全，核心含义是："即使服务器的长期私钥泄露，过去的通信数据也不会被破解"。原因是：
- 每次握手协商的会话密钥是"临时密钥"（基于 ECDH 临时密钥对），与服务器长期私钥无关。
- 长期私钥仅用于签名（认证身份），不参与会话密钥计算，泄露后仅影响未来的连接认证，不影响历史数据。
6.3 常见安全漏洞（已修复）
- Heartbleed（心脏出血）：OpenSSL 库的漏洞，攻击者可通过 TLS 心跳包读取服务器内存中的私钥、会话密钥等敏感信息（修复方式：升级 OpenSSL 版本）。
- POODLE（贵宾犬）：利用 TLS 1.0 降级攻击，破解 AES-CBC 加密的会话密钥（修复方式：禁用 TLS 1.0/1.1，使用 TLS 1.2+）。
- Logjam：破解弱 Diffie-Hellman 密钥交换（修复方式：使用 2048 位以上 DH 密钥，或改用 ECDH）。
七、总结
HTTPS 的安全核心是 TLS 协议，其本质是"通过密钥交换建立安全的对称加密通道，通过数字证书和数字签名保障身份认证"。关键流程可简化为：
- 客户端与服务器通过 ECDH 安全协商会话密钥（1 个 RTT）。
- 服务器通过数字证书证明身份（CA 签名保障证书可信）。
- 服务器通过数字签名证明自己拥有证书私钥（避免中间人伪造）。
- 后续应用数据用会话密钥加密传输（高效、安全）。
数字证书解决了"公钥信任问题"，数字签名解决了"身份认证和防篡改问题"，两者结合构成了 HTTPS 安全的基石。TLS 1.3 作为最新版本，通过简化流程、强化安全算法，成为目前最推荐的 TLS 版本，也是未来 HTTPS 的主流标准。