TLS1.3协议分析1

1.  介绍

TLS 1.3 是传输层安全协议的最新版本，由 IETF 于 2018 年标准化（RFC 8446）。它并非 TLS 1.2 的简单升级，而是一次彻底的重构和现代化，旨在解决其前任在安全和性能上的根本性缺陷。

1.1  发展历程

TLS 1.3的标准化过程是一个不断权衡安全、性能和兼容性的过程。

时间点

阶段

核心事件与里程碑

2014年4月

提案启动

IETF TLS工作组将TLS 1.3列为正式工作项目，目标是“清理协议，减少延迟，保持安全性”。

2014-2016年

草案迭代与激烈辩论

这是最关键的设计阶段。草案版本快速迭代。

核心设计确立：1-RTT完整握手和 0-RTT快速重启模式成为核心目标。

算法大清洗：移除了所有静态RSA密钥交换、CBC模式、RC4、SHA-1等不安全算法。

激烈争论点：RSA-PSS签名 的采用、握手加密范围（特别是证书是否加密）以及0-RTT的安全权衡。

2016年

重大设计变更

为应对降级攻击，设计了一个重要的保护机制：将核心密钥交换参数（ClientHello中的supported_versions扩展）设计为在计算握手 Finished MAC 时是明文的，而在计算应用流量密钥时是加密的，这使得任何试图篡改版本号的行为都会被最终发现。

2017年3月

草案定型

draft-28 发布，此版本被工作组确认为最终版本，不再进行功能性修改。

2018年3月

RFC标准化

RFC 8446 发布，标志着TLS 1.3正式成为互联网标准。

2018年至今

大规模部署与演进

 2018年：主流浏览器（Chrome, Firefox, Safari）和服务器（Nginx, Apache）开始默认支持TLS 1.3。

推广应用：从Web扩展到所有加密通信场景，如DNS over HTTPS (DoH)、QUIC协议等。

 

1.2  标准规范

RFC8446     The Transport Layer Security (TLS) Protocol Version 1.3

1.3  术语和定义

Round-Trip Time：往返时间，指一个数据包从源点发送到目的地，然后再从目的地返回一个响应包到源点所需的总时间。

客户端（client）:  发起TLS连接的端点。

连接（connection）: 两端之间的传输层连接。

端点（endpoint）:  连接的客户端或者服务器。

握手（handshake）:  客户端和服务器之间协商TLS交互的后续参数的出示协商。  

接收端（receiver）: 接收记录的端点。

发送者（sender）:  发送记录的端点。

服务器（server）:  没有发起TLS连接的端点。

HKDF：基于HMAC的密钥派生函数

1.4  缩略语

RTT: 往返时间(Round-Trip Time)

PSK:预共享密钥（pre_shared_key）

2.  协议概览

TLS1.3总共有两层，分别是握手协议(handshake protocol)和记录协议(record protocol)，握手协议在记录协议的上层，记录协议是一个分层协议。其中握手协议中还包括了警告协议(alert protocol)。

 

2.1  记录协议

位于握手协议下层，发送方从高层接受任意长度的非空数据，对其进行合并或分块处理，然后利用带有辅助数据的认证加密AEAD（authenticated encryption with associated data）进行加密传输。接收方接受数据后对其进行解密和验证，重组后再传送给高层用户。

2.2  警告协议

目的是以简单的通知机制告知通信出现异常情况，警告消息通常会携带Close_notify异常，在连接关闭的时候报告错误，Alert_Level字段标识告警的严重程度，可取值Warning或者Fatal，严重程度为Fatal时会立即终止当前连接。

2.3  握手协议

安全通道使用的密码参数由TLS握手协议生成。这个TLS的子协议在client和server第一次通信时使用。握手协议使两端协商协议版本、选择密码算法、选择性互相认证，并得到共享的密钥数据。一旦握手完成，双方就会使用得出的密钥保护应用层流量。握手失败或其它协议错误会触发连接中止，在这之前可以有选择地发送一个警报消息。

TLS1.3协议握手流程如下：

 

+表示在先前提到的消息中发送的值得注意的扩展

*表示可选或情境依赖的消息/扩展，不一定总是发送

{}表示使用从 [sender]_handshake_traffic_secret 导出的密钥保护的消息

[]表示使用从 [sender]_application_traffic_secret_N 导出的密钥保护的消息

握手可以看作有三个阶段：

2.3.1  密钥交换

选择TLS协议版本和加密的算法，并且协商算法所需的参数。这段是明文传输的。

在密钥交换阶段，客户端发送ClientHello消息，其中包含：

  • 随机的nonce（ClientHello.random)
  • 所提供的协议版本
  • 一组对称密码算法/HKDF哈希对
  • Diffie-Hellman共享密钥(在"key_share"扩展中)、预共享密钥标签集合(在"pre_shared_key"扩展中), 或两者都有
  • 可能的其他扩展

服务器处理ClientHello并确定适当的加密参数，然后通过ServerHello响应，指示协商的连接参数。

TLS支持3种基本的密钥交换模式：

  • 　　(EC)DHE (基于有限域或椭圆曲线的Diffie-Hellman)
  •  　　PSK-only
  • 　　PSK结合(EC)DHE

密钥交换模式详解

1)       (EC)DHE - ephemeral Diffie-Hellman

这是 TLS 1.3 的标准模式和推荐默认模式。绝大多数现代 HTTPS 连接都使用此模式。

  • 原理：客户端和服务器各自临时生成一对临时的 Diffie-Hellman 密钥对（可以是基于有限域的，但更常见的是基于椭圆曲线的 ECDHE）。然后双方交换公钥，利用对方的公钥和自己的私钥，独立计算出一个相同的共享密钥（预主密钥）。
  • 握手特征：
    • 在 ClientHello 中，客户端在 key_share 扩展中携带一个或多个 (EC)DHE 公钥。
    • 在 ServerHello 中，服务器在 key_share 扩展中选定并返回它自己的 (EC)DHE 公钥。
  • 优点：
    • 完美的前向安全：因为每次连接都使用临时的密钥对，计算出的共享密钥仅在本次连接中有效。即使服务器长期私钥泄露，过去的会话记录也不会被解密。
    • 广泛支持和高性能：特别是 ECDHE，在保证高安全强度的同时，计算和通信开销较小。
  • 缺点：
    • 需要完整的 1-RTT 握手。
  • 应用场景：几乎所有需要最高安全级别的场景，如网上银行、电子邮件、社交网络登录等。

2)       PSK-Only

此模式完全依赖于一个双方预先共享的密钥来建立连接。

  • 原理：客户端和服务器在 TLS 握手开始之前，就已经通过某种安全渠道共享了一个密钥。这个 PSK 通常来自于一次成功的完整 (EC)DHE 握手后，服务器通过 New Session Ticket 消息下发的会话票证。在恢复会话时，客户端直接使用这个 PSK 来派生会话密钥。
  • 握手特征：
    • 在 ClientHello 中，客户端在 pre_shared_key 扩展中提供 PSK 身份标识。
    • 服务器验证 PSK 有效后，在 ServerHello 中确认使用该 PSK。
    • 握手消息大幅减少，无需 Certificate 和 CertificateVerify。
  • 优点：
    • 极高的性能（0-RTT）：可以实现“零往返”握手，客户端在第一次消息中就可以携带加密的应用数据，极大降低延迟。
    • 节省计算资源：避免了昂贵的非对称加密运算。
  • 缺点：
    • 不具备前向安全性：如果 PSK 被泄露，所有使用该 PSK 加密的通信（包括 0-RTT 数据）都可能被解密。
    • 0-RTT 数据存在重放攻击风险：攻击者可以截获客户端发送的 0-RTT 数据并重新发送，服务器可能会多次处理该请求。
  • 应用场景：
    • 会话恢复：最常见的使用场景，用于快速恢复与已知服务器的连接。
    • 物联网或受限环境：设备预先配置了 PSK，无需复杂的证书管理。
    • 内部微服务通信：在可控的内部网络环境中，使用 PSK 简化认证和提升性能。

3)       PSK with (EC)DHE

这是前两种模式的结合，也是安全性与性能的最佳平衡点，被强烈推荐用于 PSK 模式。

  • 原理：在 PSK-Only 模式的基础上，额外增加一次 (EC)DHE 密钥交换。最终的会话密钥由 PSK 和 (EC)DHE 共享密钥 共同派生。
  • 握手特征：
    • 在 ClientHello 中，客户端同时提供 pre_shared_key 和 key_share 扩展。
    • 服务器在 ServerHello 中确认使用 PSK，并同时返回自己的 (EC)DHE 公钥。
  • 优点：
    • 保持前向安全：即使 PSK 泄露，由于每次会话都混合了新鲜的 (EC)DHE 共享密钥，过去的会话记录依然是安全的。
    • 提供身份认证：PSK 证明了客户端的身份（“我知道这个密钥”），(EC)DHE 提供了新鲜度和密钥确认。
    • 缓解 0-RTT 重放攻击：虽然不能完全消除，但结合了 DHE 的 0-RTT 模式比纯 PSK 模式更难被攻击。
  • 缺点：
    • 比 PSK-Only 模式多了一次 DHE 计算，但仍比完整的 (EC)DHE 握手要快。
  • 应用场景：
    • 需要前向安全的会话恢复：这是最理想的会话恢复方式。例如，在移动 App 与服务器的长期连接中，既要求快速恢复，又要求最高级别的安全。
    • 对安全要求高的预共享密钥场景：在任何使用 PSK 但又不愿意牺牲前向安全性的场合，都应首选此模式。

总结和对比

特性

(EC)DHE

PSK-Only

PSK with (EC)DHE

前向安全

是

否

是

性能

1-RTT

0-RTT（最优）

0-RTT 或 1-RTT

认证方式

证书

预共享密钥

预共享密钥 + 证书（间接）

主要用途

标准新连接

快速会话恢复、IoT

安全的会话恢复

推荐度

必须支持（默认）

谨慎使用

推荐（PSK场景下）

 

ClientHello和ServerHello的组合确定了共享密钥

  • 如果使用了(EC)DHE密钥协商，则ServerHello包含服务器临时生成DH公钥的key_share扩展
  • 如果使用PSK密钥协商，则ServerHello包含一个pre_shared_key扩展，指示选择了客户端提供的PSK中的哪一个
  • 请注意，实现可以同时使用(EC)DHE和PSK，在这种情况下ServerHello将提供两个扩展。

2.3.2  服务器参数

建立其他握手协议参数，例如是否需要认证客户端，支持何种应用层协议等。

  • EncryptedExtensions：对于不需要确定密码参数的ClientHello扩展的响应。
  • CertificateRequest：如果需要客户端身份证书验证，则为该证书的所需参数。如果不需要客户端身份验证，则省略此消息

2.3.3  认证

客户端和服务器交换身份验证消息。具体消息如下：

Certificate：服务端证书和证书相关的扩展，如果不使用证书进行身份验证，则服务器会省略此消息；如果使用原始公钥或缓存的信息，则此消息将不包含证书，而是包含与服务器的长期密钥对应的其他信息。

CertificateVerify：使用Certificate消息中公钥对应的私钥对整个握手消息进行签名，如果不通过证书进行身份验证，则省略此消息。

Finished：对应整个握手的消息认证码MAC，此消息提供密钥确认，将客户端/服务端的身份与交换的密钥绑定，并在PSK模式下还进行握手身份验证。

posted @ 2025-11-05 16:31  情殇王子  阅读(88)  评论(0)    收藏  举报