鸭梨公共文档

主题

HTTPS 通信原理与流程 ​

1. 通信流程示意图 ​

HTTPS 通信过程通过 SSL/TLS 协议在 HTTP 协议栈中插入安全层，核心流程分为 6 个阶段，涉及非对称加密、对称加密和散列算法协同工作：

2. 核心阶段详解 ​

  1. 协商阶段 (Handshake Initiation)

    • ClientHello：客户端发送支持的 TLS 版本（如 TLS 1.3）、32 字节客户端随机数（Client Random）、加密套件列表（如 TLS_AES_256_GCM_SHA384）
    • ServerHello：服务器响应选定的协议版本、32 字节服务器随机数（Server Random）、确定加密套件

  2. 证书验证阶段 (Authentication)

    • 服务器发送数字证书链（X.509 v3），包含：
      • 域名信息
      • 公钥（RSA 2048/EC P-256）
      • CA 签名（使用 SHA-256WithRSAEncryption）
    • 客户端验证证书链的信任链、有效期、吊销状态（OCSP/CRL）

  3. 密钥交换阶段 (Key Exchange)

    • RSA 模式（已逐渐淘汰）：
      • 客户端生成 48 字节预主密钥（Premaster Secret）
      • 用服务器公钥加密后发送
    • ECDHE 模式（现代主流）：
      python
      # 椭圆曲线参数协商示例
server_priv = generate_private_key(secp256r1)
server_pub = server_priv.public_key()
client_priv = generate_private_key(secp256r1)
client_pub = client_priv.public_key()
shared_secret = client_priv.exchange(server_pub)

  4. 会话密钥生成 (Key Derivation) 使用 HKDF 算法生成主密钥：

    python
    master_secret = PRF(
    premaster_secret + 
    client_random + 
    server_random, 
    "master secret", 
    48
)

    最终生成 4 个密钥：

    • 客户端写 MAC 密钥
    • 服务器写 MAC 密钥
    • 客户端写加密密钥（AES-256-GCM）
    • 服务器写加密密钥

  5. 完成验证 (Handshake Verification) 双方发送加密的 Finished 消息，使用 HMAC 验证握手完整性：

    python
    verify_data = HMAC(
    master_secret, 
    SHA256(handshake_messages)
)

  6. 加密通信阶段 (Secure Data Transfer) 使用协商的对称加密算法（如 AES-GCM）进行数据加密，每个记录层包含：

    • 加密内容
    • GCM 认证标签（128位）
    • 序列号（防重放攻击）

在协商阶段，客户端和服务器选择加密套件时，会根据安全性和性能需求选择合适的组合，如：

text
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
├─ 密钥交换: ECDHE_RSA
├─ 认证算法: RSA
├─ 批量加密: AES-256-GCM
└─ 摘要算法: SHA-384

3. 前向保密增强 ​

现代配置优先选择 ECDHE 密钥交换，即使服务器私钥泄露，历史会话仍能保证安全。Cloudflare 统计显示，2023 年 98% 的 HTTPS 连接使用 ECDHE 交换机制。

ECDHE（Elliptic Curve Diffie-Hellman Ephemeral）是一种结合椭圆曲线密码学与临时密钥的密钥交换协议，广泛应用于 TLS/SSL 等安全通信协议中。其核心流程可分为以下几个关键步骤：

3.1 椭圆曲线参数协商 ​

双方首先约定使用相同的椭圆曲线参数组：

text
Curve: secp256r1 (NIST P-256)
Prime modulus p = 2²⁵⁶ - 2²²⁴ + 2¹⁹² + 2⁹⁶ - 1
Base point G = (x₀, y₀)  # 曲线上的生成元

这些参数通过数字证书或协议握手阶段传输。现代 TLS 最常使用 secp256r1、secp384r1 等标准化曲线。

3.2 密钥对生成 ​

每个参与方独立生成临时密钥对：

其中 n 是椭圆曲线的阶数，a·G 表示椭圆曲线上的标量乘法运算。私钥必须严格保密，公钥通过不安全的信道交换。

3.3 共享密钥计算 ​

双方利用对方公钥生成共享密钥：

  • Alice 计算：S=a⋅B=a⋅(b⋅G)=ab⋅GS = a \cdot B = a \cdot (b \cdot G) = ab \cdot G
  • Bob 计算：S=b⋅A=b⋅(a⋅G)=ab⋅GS = b \cdot A = b \cdot (a \cdot G) = ab \cdot G

由于椭圆曲线离散对数问题（ECDLP）的困难性，攻击者即使截获 A 和 B 也无法计算出 ab·G。最终共享密钥通常取 S 的 x 坐标经过 KDF（密钥派生函数）处理得到。

3.4 前向安全性保障 ​

ECDHE 的 "Ephemeral" 特性体现在：

  • 每次会话生成新密钥对
  • 私钥仅在当前会话有效
  • 即使长期私钥泄露，历史会话仍安全

下表对比了不同 DH 变体的特性：

类型密钥复用性前向安全计算开销
DH长期使用❌高
DHE单次使用✅高
ECDHE单次使用✅低

3.5 TLS 中的实际应用 ​

在 TLS 握手协议中，ECDHE 的执行流程如下：

  1. Client Hello：客户端支持曲线列表
  2. Server Hello：服务端选择曲线类型
  3. Server Key Exchange：发送服务端公钥 + 数字签名
  4. Client Key Exchange：发送客户端公钥
  5. 双方计算 Premaster Secret

最终主密钥通过 PRF（伪随机函数）生成：

master_secret=PRF(pre_master_secret,"mastersecret",ClientHello.random∣∣ServerHello.random)\rm master\_secret = PRF( pre\_master\_secret, "master secret", ClientHello.random || ServerHello.random )

3.6 安全性分析 ​

ECDHE 的安全性依赖于：

  • ECDLP 困难性：无法从公钥推导私钥
  • 临时密钥机制：实现完美前向保密
  • 随机数质量：私钥必须密码学安全随机生成
  • 签名验证：防止中间人攻击（需配合证书体系）

通过 NIST P-256 曲线，ECDHE-ECDSA 在 128 位安全级别下仅需 256 位密钥，而传统 DH 需要 3072 位 RSA 密钥，显著提升了计算效率。

相关文档 ​