🦌鹿心雨的小窝🦌
🦌鹿心雨的小窝
coverPiccoverPic

关于 HTTPS 的笔记 2.0

HTTPS计算机网络

前言

HTTPS 是 HTTP 的“升级”版本：HTTPS = HTTP + SSL/TLS，SSL 是安全层，TLS 是传输层安全，是 SSL 的继承。使用 SSL 或 TLS 可确保传输数据的安全性。

前文见 https://deer.shika-blog.xyz/web/article/131

这篇博客是 HTTPS 相关的笔记

CA 验证机制

CA 证书的核心功能是验证服务器身份。服务器从受信任的证书颁发机构获取包含其公钥的数字证书。当客户端连接时，服务器发送此证书供验证。

CA 使用私钥对证书内容生成签名，客户端使用预置的 CA 公钥验证该签名。若验证通过，则确认证书真实有效且未被篡改。

此机制可以防止中间人攻击。攻击者无法伪造有效签名，客户端通过验证失败即可识别伪造证书。只有通过验证后，客户端才信任证书中的公钥属于目标服务器，为安全通信建立基础。

客户端验证流程：

  1. 检查证书域名、有效期等信息
  2. 使用操作系统/浏览器预置的 CA 公钥解密数字签名
  3. 对比解密后的哈希值与证书实际内容的哈希值
  4. 两者一致则证书可信，否则拒绝连接

TLS 1.2 版本的握手流程

  1. ClientHello
    • 客户端连接服务器 443 端口（TCP 三次握手）
    • 发送客户端随机数 R1
    • 提供支持的密码套件列表
  2. ServerHello
    • 服务器返回服务器随机数 R2
    • 确定使用的密码套件
    • 发送数字证书链
  3. 密钥交换与认证
    • 客户端验证证书有效性
    • 生成 Pre-master Key（随机数 R3）
    • 使用服务器公钥加密 R3 并发送
  4. 完成握手
    • 服务器使用私钥解密获得 R3
    • 双方基于 R1 + R2 + R3 生成相同的会话密钥
    • 交换 Finished 消息确认握手成功
sequenceDiagram
    note left of Client: 生成随机数 R1
    note right of Client: 随机数 R1、客户端支持的加密算法
    Client->>Server: Client Hello
    Server->>Client: ACK
    note right of Server: 生成随机数 R2
    note left of Server: 随机数 R2、会话密钥生成算法、TLS 版本
    Server->>Client: Server Hello
    note right of Server: 使用 CA 私钥加密明文的 Hash 形成数字签名
    note left of Server: 服务端证书
包含证书格式、版本号、序列号、有效期、颁发者、服务器公钥、数字签名...
    Server->>Client: Server Certificent
    Server->>Client: Server Hello Done
    Client->>Server: ACK
    note left of Client: 在发送ACK后
1、先验证明文部分，看看是否过期，网址是否正确。
2、再用在操作系统或者浏览器上内置的 CA 公钥把数字签名解密。
然后判断和证书中的明文的hash值是否相等，
不相等说明被篡改了，停止交易（x）。
3、验证阶段还有一些其他东西，比如如果找不到这个CA证书。
服务器会返回一个证书，让你选择是否信任。
    note left of Client: 生成随机数 R3。然后用公钥加密 R3 生成一个 Pre-Master Key
    note right of Client: 随机数 R3，即 Pre-Master Key
    Client->>Server: Client Key Exchange
    note right of Server: 服务器使用私钥解密获得 R3，
此时双方都拥有 3 个随机数 R1、R2、R3，
通过双方选择的加密算法计算出会话密钥 Session Key
    note right of Client: 表示后续使用会话密钥进行通信
    Client->>Server: Change Cipher Spec
    note right of Client: 会话握手所有数据的 Hash
    Client->>Server: Finish
    note right of Server: 验证 Hash 是否和自己算出来的一样
    Server->>Client: ACK
    Server->>Client: Change Cipher Spec
    note left of Server: 会话握手所有数据的 Hash
    Server->>Client: Finish
    note left of Client: 验证 Hash 是否和自己算出来的一样
    Client->>Server: ACK
    Note over Client,Server: 之后使用会话密钥进行加密通信

TLS 1.3 安全模型改进

TLS 1.2 采用混合安全模型，依赖非对称加密传输预主密钥，结合客户端与服务端的随机数生成会话密钥。该模型支持静态RSA密钥交换，存在前向安全风险，且握手过程需要两次往返。

TLS 1.3 彻底重构了密钥交换机制。协议摒弃了 TLS 1.2 中基于非对称加密传输预主密钥的混合模型，转而强制采用基于临时 Diffie-Hellman 的密钥协商机制（DHE）。该模型通过在握手初期交换临时公钥参数，使通信双方能够独立计算共享密钥，完全消除了密钥材料在信道中的传输需求。这一改进不仅提供了内在的前向安全性，还将握手延迟从两次往返缩减至单次往返，同时通过移除不安全的密码学原语显著缩小了攻击面。

前向安全：前向安全是密码学中通讯协议的安全属性，指长期使用的主密钥泄漏不会导致过去的会话密钥泄漏

密码学原语：密码学原语指的是一类密码算法，例如，对称加密是一个密码原语，而 AES 是一个具体的对称加密算法

DHE：临时 Diffie-Hellman，DHE 中的 “E” 代表 “Ephemeral”；ECDHE：椭圆曲线临时 Diffie-Hellman，基于椭圆曲线密码学的升级版本，目前主流的版本。

密钥协商机制示意图：

sequenceDiagram
    participant Client
    participant Server
    
    Note over Client, Server: TLS 1.3 基于 (EC)DHE 的密钥协商
    
    Note left of Client: 生成临时密钥对
(client_private, client_public)
    Client->>Server: ClientHello + key_share
client_public
    
    Note right of Server: 生成临时密钥对
(server_private, server_public)
    Server->>Client: ServerHello + key_share
server_public
    
    Note left of Client: 计算共享密钥：
DH(client_private, server_public)
    Note right of Server: 计算共享密钥：
DH(server_private, client_public)
    
    Note over Client, Server: 双方独立计算出相同共享密钥
实现前向安全，无密钥材料传输

TLS 1.3 版本握手流程

  1. ClientHello（客户端公钥、客户端随机数、支持密码套件）

  2. ServerHello（服务端公钥、服务端随机数、选定的密码套件）

    • 证书和 Finished 等内容，是在 ServerHello 之后，通过独立的 TLS 记录（EncryptedExtensions、Certificate、CertificateVerify、Finished）分步发送的，并且这些消息在 TLS 1.3 中已经开始使用计算出的会话密钥进行加密了。

  3. 客户端 Finished，立即开始应用数据传输

我们可能没有看到 TLS 1.2 版本有选择签名算法的步骤，这是因为:
在 TLS 1.2 中，签名算法的选择主要不是通过独立的协商，而是隐含在密码套件的名称中。例如，当密码套件 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，其中的 RSA 就指定了服务器必须使用 RSA 签名算法来对 ECDHE 参数进行签名；而套件 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 中的 ECDSA 则指定了使用 ECDSA 算法。虽然 TLS 1.2 也定义了 signature_algorithms 扩展，但它主要扮演辅助角色，用于告知服务器客户端支持哪些哈希和签名算法组合来验证其证书链。

sequenceDiagram
    participant Client
    participant Server

    Note over Client,Server: TLS 1.3 Full Handshake (1-RTT)

    Client->>Server: ClientHello
client_random: [32字节随机数]
cipher_suites: [支持的加密套件列表]
key_share: [客户端DH公钥参数]
signature_algorithms: [支持的签名算法]
supported_versions: [TLS 1.3]
    
    Server->>Client: ServerHello
server_random: [32字节随机数]
cipher_suite: [选定的加密套件]
key_share: [服务器DH公钥参数]
supported_version: [TLS 1.3]
    
    Server->>Client: EncryptedExtensions
[加密的扩展参数，如ALPN等]
    
    Server->>Client: Certificate
certificate_list: [证书链，包含服务器证书和中间CA证书]
extensions: [证书扩展]
    
    Server->>Client: CertificateVerify
algorithm: [签名算法如ECDSA/RSA]
signature: [对握手消息的签名]
    
    Server->>Client: Finished
verify_data: [HMAC(handshake_messages, session_key)]
    
    Client->>Server: Finished
verify_data: [HMAC(handshake_messages, session_key)]
    
    Note over Client,Server: Application Data
使用session_key加密的应用层数据

TLS 1.3 0-RTT 工作机制

TLS 1.3 的 0-RTT（零往返时间）机制通过预共享密钥（PSK）实现瞬时连接。其核心原理是复用之前成功握手建立的会话信息。

在首次完整握手（Full Handshake，即 1-RTT Handshake）时，服务器会在安全通道建立后（通常在发送完 Finished 消息之后），向客户端发送一个"新会话票证"（New Session Ticket）。这个票证包含由主密钥（Master Secret）衍生的会话恢复主密钥（Resumption Master Secret）、票证的生命周期（Lifetime）以及其他会话上下文信息。客户端将此票证（Ticket）及其对应的密钥材料安全存储。

当客户端需要重新连接同一服务器时，它直接在初始 ClientHello 消息中携带此会话票证（Session Ticket），并可以立即发送加密的应用数据，即"早期数据"（Early Data）。这些早期数据是客户端希望在握手完成前发送的实际业务数据（如 HTTP 请求），使用基于上次会话衍生的 Resumption Master Secret 进行加密。

服务器收到请求后，通过验证票证的有效性，能够立即使用之前协商的密钥材料解密并处理这些早期数据，无需等待握手完成。这种机制将重复连接的延迟降至理论最低值（0-RTT）。

在 ServerHello 之后，通信双方会基于新的 (EC)DHE shared secret 和新的随机数，推导出一套全新的、独立的连接密钥（或称为流量密钥），用于加密本次连接后续的所有应用数据。这套新密钥基于本次握手交换的新随机数（ClientHello.random 和 ServerHello.random）以及可能的新的密钥共享材料（如 (EC)DHE shared secret），通过密钥派生函数（HKDF）生成，确保了前向安全性（Forward Secrecy）。自此，所有在早期数据之后的应用数据都将使用这套全新的密钥进行加密。

然而，0-RTT 数据面临重放攻击风险：攻击者可能拦截并重复发送加密的 0-RTT 数据包。为缓解此风险，TLS 1.3 建议对非等幂操作禁用 0-RTT，或由应用层实现重放保护机制。

目前，主流的 TLS 库（如 OpenSSL）和浏览器在实现 0-RTT 时，出于安全考虑，通常会采用混合模式，即包含 (EC)DHE shared secret。

sequenceDiagram
    participant Client
    participant Server
    Note over Client,Server: 1-RTT 连接建立完成
    Server->>Client: New Session Ticket
(包含resumption_master_secret)
    Note left of Client: 安全存储会话票证
和密钥材料
    Note over Client,Server: TLS 1.3 0-RTT Mechanism

    Note left of Client: 使用之前存储的
New Session Ticket
取出会话票证和密钥

    Client->>Server: ClientHello
pre_shared_key: [会话票证]
psk_key_exchange_modes: [PSK密钥交换模式]
early_data: [加密的0-RTT数据]
key_share: [可选的DH参数]
其他标准ClientHello参数
    
    Note right of Server: 1. 验证会话票证
2. 提取resumption_master_secret
3. 立即解密处理early_data
    
    Server->>Client: ServerHello
pre_shared_key: [确认的PSK]
encrypted_extensions: [包括early_data扩展]
其他标准ServerHello参数
    
    Note over Client,Server: 基于新随机数和DH参数
生成全新会话密钥
    
    Server->>Client: Finished
verify_data: [HMAC(handshake_messages)]
    
    Client->>Server: Finished
verify_data: [HMAC(handshake_messages)]
    
    Note over Client,Server: 继续正常加密通信
使用全新会话密钥
0-RTT数据已在首包中传输完成
    
    Server->>Client: New Session Ticket
(用于下一次0-RTT连接)

TLS 1.3 的优势

性能优化

TLS 1.3 在性能方面大幅优化，将完整握手过程从 TLS 1.2 的 2-RTT 缩减至 1-RTT。这一改进通过客户端在初始 ClientHello 消息中预置密钥共享材料来实现，消除了传统握手过程中单独的密钥交换回合。

引入的 0-RTT 会话恢复模式使得重复访问的客户端可以实现零往返延迟，极大提升了用户体验，不过需要注意这种模式可能存在重放攻击的风险。

安全增强

在安全层面，TLS 1.3 通过彻底移除不安全算法来大幅缩减攻击面。它禁用了缺乏前向安全性的静态 RSA 密钥交换，移除了存在漏洞的 CBC 模式加密和 RC4 流加密，同时淘汰了 SHA-1、MD5 等弱哈希算法。此外，还取消了压缩支持以有效防范 CRIME 攻击。

架构简化

TLS 1.3 在架构设计上实现了显著简化，握手过程中的大部分内容都实现了加密传输，有效增强了用户隐私保护。密码套件经过大幅精简，仅保留经过严格验证的安全方案，同时默认使用具有前向安全性的 ECDHE 密钥交换。

上一篇：实现 Promise A+ 规范的 Promise
下一篇：Antd 在 Next.js 项目中，初次渲染样式丢失
0 条评论未登录用户
Ctrl or + Enter 评论
© 2023-2025 LittleRangiferTarandus, All rights reserved.
🌸 Run