1.1. 约定与 术语

本文档中的关键词“必须”、“不得 ”、“要求”、“须”、 “不得”、“应”、“不应”、“建议”、“不建议”、 “可以”和“可选”， 只有在如本文所示以全大写形式出现时， 才应按照 BCP 14 [RFC2119] [RFC8174] 中的说明进行解释。¶

使用以下术语：¶

客户端：

发起 TLS 连接的端点。¶

连接：

两个端点之间的传输层连接。¶

端点：

连接的客户端或服务器。¶

握手：

客户端与服务器之间的初始协商，用于确定 它们随后在 TLS 中交互的参数。¶

对等方：

一个端点。在讨论某个特定端点时，“对等方”是指 并非讨论主要对象的另一个端点。¶

接收方：

正在接收记录的端点。¶

发送方：

正在传输记录的端点。¶

服务器：

未发起 TLS 连接的端点。¶

1.2. 与 RFC 8446 的关系

TLS 1.3 最初在 [RFC8446] 中规定。本文档是对 TLS 1.3 的小幅更新，保留相同版本号并且 向后兼容。它收紧了一些要求，并在被发现表述不清的部分 更新了文本，同时进行了其他 编辑性改进。此外，它不再将术语 “master”用于秘密值，而是改用“main”，或在不需要术语时 使用更短的名称。本文档进行了以下 具体技术变更：¶

• 禁止在不同连接之间复用 KeyShare 值。¶

• 禁止协商 TLS 1.0 和 1.1，因为它们现已被 [RFC8996] 废弃。¶

• 消除 PreSharedKeys 和 HelloRetryRequest 使用哪种哈希函数的歧义。¶

• 要求不支持恢复的客户端忽略 NewSessionTicket。¶

• 将超过密钥 使用限制前必须发起密钥更新的要求提升为必须，并明确密钥使用 限制的适用范围。¶

• 限制允许发送的 KeyUpdate 消息数量。¶

• 恢复将“close_notify”级别定义为“warning”的文本。¶

• 明确“user_canceled”相关行为，要求发送 “close_notify”，并且应 忽略“user_canceled”。¶

• 添加通用“general_error”警报。¶

• 将 CertificateRequest.extensions 的下限修正为 0 字节。原语法存在错误，因为 可以不发送任何扩展，此时 长度为 0。¶

• 修正 ClientHello.extensions 的下限。这 是一个计算错误。¶

• 修正 NewSessionTicket.extensions 的上限。 这是一个计算错误。¶

• 对非对称密钥交换使用更通用的表述， 其此前仅指（EC）DHE， 以反映基于 KEM 的密钥交换的使用。¶

• 明确消息记录哈希与 未来规范之间的交互。¶

• 删除要求 RSA PSS 的文本，与 [RFC9963] 保持一致。¶

此外，安全注意事项也进行了一些改进， 尤其是隐私方面。¶

1.3. 与 TLS 1.2 的主要区别

以下列出了 TLS 1.2 与 TLS 1.3 之间的主要功能差异。 该列表并非穷尽无遗， 还存在许多细微差异。¶

• 支持的对称加密算法列表中已移除所有 被视为旧式的算法。其余算法均为带关联数据的认证加密 （AEAD）算法。密码套件的概念已更改，将身份验证和密钥交换机制 与记录保护算法（包括秘密密钥长度）以及同时用于 密钥派生函数和握手消息 身份验证代码（MAC）的哈希函数分离。¶

• 新增零往返时间（0-RTT）模式，对于 某些应用数据，可在建立连接时节省一次往返， 代价是牺牲某些安全属性。¶

• 已移除静态 RSA 和 Diffie-Hellman 密码套件； 现在所有基于公钥的密钥交换机制都提供前向保密性。¶

• ServerHello 之后的所有握手消息现在均经过加密。 新引入的 EncryptedExtensions 消息使此前 在 ServerHello 中以明文发送的各种扩展也能获得 机密性保护。¶

• 密钥派生函数已重新设计。新设计凭借更强的密钥分离 属性，使密码学家能够更轻松地进行分析。 基于 HMAC 的提取并扩展密钥派生函数（HKDF） 被用作底层原语。¶

• 握手状态机经过大幅重构，使其 更加一致，并移除了 ChangeCipherSpec 等多余消息 （中间盒兼容性需要时除外）。¶

• 椭圆曲线算法现已纳入基础规范，并 加入了 EdDSA 等新的签名 算法。TLS 1.3 移除了点格式 协商，改为每条曲线仅使用一种点格式。¶

• 还进行了其他密码学改进，包括将 RSA 填充改为使用 RSA 概率签名方案（RSASSA-PSS），并移除 压缩、数字签名算法（DSA）以及 自定义临时 Diffie-Hellman（DHE）组。¶

• TLS 1.2 的版本协商机制已被废弃，改为 在扩展中提供版本列表。这提高了与 错误实现版本协商的现有服务器的兼容性。¶

• 有服务器端状态和无服务器端状态的会话恢复，以及 早期 TLS 版本中基于 PSK 的密码套件，均由一种新的 PSK 交换机制取代。¶

• 参考文献已在适当情况下更新为指向新版 RFC（例如 RFC 5280，而不是 RFC 3280）。¶

1.4. 影响 TLS 1.2 的更新

本文档定义了若干可选择影响 TLS 1.2 实现的变更，包括那些并不同时 支持 TLS 1.3 的实现：¶

• 第 4.2.3 节描述了版本降级保护机制。¶

• 第 4.3.3 节定义了 RSASSA-PSS 签名方案。¶

• 可以使用“supported_versions”ClientHello 扩展 协商 要使用的 TLS 版本，优先于 ClientHello 的 legacy_version 字段。¶

• “signature_algorithms_cert”扩展允许客户端 指明 它能够在 X.509 证书中验证哪些签名算法。¶

• 已移除用于秘密值的术语“master”，并将 “extended_master_secret”扩展 [RFC7627] 重命名为 “extended_main_secret”。¶

此外，本文档明确了早期 TLS 版本的一些合规要求； 请参阅第 9.3 节。¶

2.1. 错误的 DHE 共享值

如果客户端未提供足够的“key_share”扩展（例如， 其中仅包含服务器无法接受或不支持的 DHE 或 ECDHE 组）， 服务器将通过 HelloRetryRequest 纠正此不匹配， 客户端则需要使用适当的 “key_share”扩展重新开始握手，如图 2 所示。 如果无法协商出共同的密码参数， 服务器必须使用适当的警报中止握手。¶

      客户端                                               服务器

      ClientHello
      + key_share             -------->
                                                HelloRetryRequest
                              <--------               + key_share
      ClientHello
      + key_share             -------->
                                                      ServerHello
                                                      + key_share
                                            {EncryptedExtensions}
                                            {CertificateRequest*}
                                                   {Certificate*}
                                             {CertificateVerify*}
                                                       {Finished}
                              <--------       [应用数据*]
      {Certificate*}
      {CertificateVerify*}
      {Finished}              -------->
      [应用数据]              <------->        [应用数据]

注意：握手消息记录包含初始的 ClientHello/HelloRetryRequest 交换；它不会因新的 ClientHello 而重置。¶

TLS 还允许基本握手的若干优化变体， 如以下各节所述。¶

2.2. 恢复与 预共享密钥（PSK）

尽管 TLS PSK 可以在外部建立， PSK 也可以在先前连接中建立， 随后用于建立新连接（使用 PSK 进行“会话恢复”或“恢复”）。 握手完成后，服务器可以 向客户端发送与从初始握手派生的唯一密钥相对应的 PSK 身份 （参见第 4.7.1 节）。 随后，客户端 可以在未来的握手中使用该 PSK 身份，协商使用 关联的 PSK。如果服务器接受该 PSK，则 新连接的安全上下文在密码学上与原始连接绑定，并使用从 初始握手派生的密钥引导密码状态， 而不进行完整握手。 在 TLS 1.2 及更早版本中，此功能由“会话 ID”和 “会话票据”[RFC5077]提供。这两种 机制均已在 TLS 1.3 中废止。¶

PSK 可以与非对称密钥交换结合使用，从而在使用共享密钥的同时 提供前向保密性；也可以单独使用， 代价是应用数据失去前向保密性。¶

图 3展示了一对握手，其中第一次握手建立 PSK，第二次握手使用它：¶

       客户端                                               服务器

初始握手：
       ClientHello
       + key_share               -------->
                                                       ServerHello
                                                       + key_share
                                             {EncryptedExtensions}
                                             {CertificateRequest*}
                                                    {Certificate*}
                                              {CertificateVerify*}
                                                        {Finished}
                                 <--------     [应用数据*]
       {Certificate*}
       {CertificateVerify*}
       {Finished}                -------->
                                 <--------      [NewSessionTicket]
       [应用数据]                <------->      [应用数据]


后续握手：
       ClientHello
       + key_share*
       + psk_key_exchange_modes
       + pre_shared_key          -------->
                                                       ServerHello
                                                  + pre_shared_key
                                                      + key_share*
                                             {EncryptedExtensions}
                                                        {Finished}
                                 <--------     [应用数据*]
       {Finished}                -------->
       [应用数据]                <------->      [应用数据]

由于服务器通过 PSK 进行身份验证，因此不会发送 Certificate 或 CertificateVerify 消息。当客户端通过 PSK 提供恢复时， 它应同时向服务器提供“key_share”扩展， 使服务器能够在需要时拒绝恢复并回退 到完整握手。服务器以“pre_shared_key” 扩展作出响应，以协商使用 PSK 密钥建立，并且可以（如图所示） 以“key_share”扩展作出响应，执行非对称密钥建立， 从而提供前向保密性。¶

在外部配置 PSK 时，还必须配置 PSK 身份以及 要与 PSK 一起使用的 KDF 哈希算法。¶

注意：使用外部配置的预共享秘密值时，一项关键 考虑是在生成密钥时使用足够的熵， 如 [RFC4086] 中所述。从密码或其他 低熵来源派生共享秘密值并不安全。低熵秘密值或密码 容易受到基于 PSK 绑定器的字典攻击。即使与 非对称密钥建立结合使用，规定的 PSK 身份验证也不是一种强健的基于密码的认证密钥交换。具体而言， 它无法阻止能够观察握手的攻击者 对密码/预共享密钥实施暴力破解攻击。¶

2.3. 0-RTT 数据

当客户端与服务器共享 PSK（从外部获取或 通过先前握手获取）时，TLS 1.3 允许客户端在 第一个消息批次中发送数据（“早期数据”）。客户端使用 PSK 验证 服务器的身份并加密早期数据。¶

如图 4所示，0-RTT 数据只是在第一个消息批次中添加到 1-RTT 握手中。握手的其余部分使用与采用 PSK 恢复的 1-RTT 握手相同的消息。¶

      客户端                                               服务器

      ClientHello
      + early_data
      + key_share*
      + psk_key_exchange_modes
      + pre_shared_key
      (应用数据*)             -------->
                                                      ServerHello
                                                 + pre_shared_key
                                                     + key_share*
                                            {EncryptedExtensions}
                                                    + early_data*
                                                       {Finished}
                              <--------       [应用数据*]
      (EndOfEarlyData*)
      {Finished}              -------->
      [应用数据]              <------->        [应用数据]

            +  表示在前述消息中发送的
               值得注意的扩展。

            *  表示并非始终发送的可选或
               依情况而定的消息/扩展。

            () 表示使用派生自
               client_early_traffic_secret 的密钥保护的消息。

            {} 表示使用派生自
               [sender]_handshake_traffic_secret 的密钥保护的消息。

            [] 表示使用派生自
               [sender]_application_traffic_secret_N 的密钥保护的消息。

重要说明：0-RTT 数据的安全属性弱于 其他类型的 TLS 数据。具体而言：¶

1. 协议不为此类数据提供任何前向保密性保证。 服务器的行为决定适用何种前向保密性保证（如果有） （参见第 8.1 节）。此 行为不会作为协议的一部分告知客户端。 因此，在缺乏有关服务器行为的带外信息时， 客户端应假定此类数据不具备前向保密性。¶

2. 不同连接之间不保证不可重放。 普通 TLS 1.3 1-RTT 数据的重放保护 由服务器的 Random 值提供，但 0-RTT 数据并不依赖 ServerHello，因此其保证较弱。如果数据通过 TLS 客户端 身份验证或在应用协议内部进行身份验证， 这一点尤其重要。同样的警告 适用于 early_exporter_secret 的任何使用。¶

0-RTT 数据无法在同一连接内重复（即服务器不会 在同一连接中处理两次相同数据），攻击者也无法 使 0-RTT 数据看起来像 1-RTT 数据 （因为它们使用不同的密钥进行保护）。附录 F.5 描述了潜在攻击，而第 8 节 描述了服务器可用于限制重放影响的机制。¶

3.1. 基本块大小

所有数据项的表示形式均被明确规定。基本数据 块大小为一个字节（即 8 位）。多字节数据项是 从左到右、从上到下拼接的字节序列。从字节 流中，按以下方式（使用 C 记法）构成多字节项（以下示例中为数值）：¶

   value = (byte[0] << 8*(n-1)) | (byte[1] << 8*(n-2)) |
           ... | byte[n-1];

多字节值的这种字节顺序就是常见的网络字节序， 即大端格式。¶

3.2. 其他

注释以“/*”开头，以“*/”结尾。¶

包含未经解释数据的单字节实体属于 opaque 类型。¶

现有类型 T 的类型别名 T' 定义如下：¶

   T T';

3.3. 数字

基本数值数据类型是无符号字节（uint8）。所有更大的数值 数据类型均由固定长度的字节序列构成，并按照 第 3.1 节所述方式拼接，且同样 为无符号类型。预定义了以下数值 类型。¶

   uint8 uint16[2];
   uint8 uint24[3];
   uint8 uint32[4];
   uint8 uint64[8];

此处以及规范其他部分中的所有值均按网络字节 （大端）顺序传输；由十六进制字节 01 02 03 04 表示的 uint32 等同于十进制值 16909060。¶

3.4. 向量

向量（一维数组）是同构数据元素组成的流。 出于表示目的，本规范将向量称为列表。 向量的大小可以在编写文档时指定，也可以留到 运行时再确定。无论哪种情况，长度声明的都是向量中的 字节数，而不是元素数。定义类型 T 的固定长度向量 新类型 T' 的语法为¶

   T T'[n];

此处，T' 在数据流中占据 n 个字节，其中 n 是 T 大小的整数倍。编码后的流中不包含向量长度。¶

在以下示例中，Datum 被定义为协议不解释的 三个连续字节，而 Data 是三个连续的 Datum， 总共占用九个字节。¶

   opaque Datum[3];      /* 三个未经解释的字节 */
   Datum Data[9];        /* 三个连续的 3 字节向量 */

变长向量通过使用 <floor..ceiling> 记法指定合法长度的 闭合子范围来定义。编码时， 实际长度在字节流中位于向量内容之前。长度 以数值形式表示，占用足以容纳向量指定的 最大长度（ceiling）所需的字节数。实际长度字段为 零的变长向量称为空向量。¶

   T T'<floor..ceiling>;

在以下示例中，“mandatory”是一个必须包含 300 到 400 个 opaque 类型字节的向量。它永远不能为空。实际长度字段 占用两个字节，即 uint16，足以表示值 400 （参见第 3.3 节）。类似地，“longer”最多可以表示 800 字节的 数据，即 400 个 uint16 元素，并且它可以为空。其编码将在 向量前添加一个两字节的实际长度字段。编码后向量的长度 必须恰好是单个元素长度的整数倍（例如， 17 字节的 uint16 向量是非法的）。¶

   opaque mandatory<300..400>;
         /* 长度字段为两个字节，不能为空 */
   uint16 longer<0..800>;
         /* 零到 400 个 16 位无符号整数 */

3.5. 枚举

还提供一种额外的稀疏数据类型，称为“enum”或 “enumerated”。每个定义都是不同的类型。只有相同类型的枚举值 才能相互赋值或比较。枚举中的每个元素 都必须赋予一个值，如以下 示例所示。由于枚举元素无序，因此可以 按任意顺序为其分配任意唯一值。¶

   enum { e1(v1), e2(v2), ... , en(vn) [[, (n)]] } Te;

协议的未来扩展或补充可以定义新值。 除非字段定义另有规定，否则实现需要能够解析并忽略未知值。¶

枚举在字节流中占用的空间等同于其最大 已定义序数值所需的空间。以下定义将使用一个字节 承载 Color 类型的字段。¶

   enum { red(3), blue(5), white(7) } Color;

可以选择指定一个没有关联标签的值，以便在不定义多余元素的情况下 强制规定宽度。¶

在以下示例中，Taste 将在数据流中占用两个字节， 但在当前协议版本中只能取值 1、2 或 4。¶

   enum { sweet(1), sour(2), bitter(4), (32000) } Taste;

枚举元素的名称作用域位于所定义的类型内。 在第一个示例中，对枚举第二个元素的完全限定引用 应为 Color.blue。如果赋值目标已明确指定， 则不需要这种限定。¶

   Color color = Color.blue;     /* 过度指定，合法 */
   Color color = blue;           /* 正确，类型隐含 */

分配给枚举值的名称不需要唯一。数值 可以描述同一名称适用的范围。该值包含 范围内的最小值和最大值，并以两个句点 字符分隔。这主要用于预留值空间中的区域。¶

   enum { sad(0), meh(1..254), happy(255) } Mood;

3.6. 复合类型

为方便起见，可以使用基本类型构造结构类型。每个 声明都会定义一个新的唯一类型。定义所使用的语法 与 C 的语法非常相似。¶

   struct {
       T1 f1;
       T2 f2;
       ...
       Tn fn;
   } T;

可以使用标准列表 语法定义定长和变长列表（向量）字段。变体示例（第 3.8 节）中的结构 V1 和 V2 展示了这一点。¶

结构中的字段可以使用类型名称进行限定， 其语法与枚举可用的语法非常相似。例如，T.f2 指 前述声明中的第二个字段。¶

3.7. 常量

可以使用“=”为字段和变量赋予固定值，如下所示：¶

   struct {
       T1 f1 = 8;  /* T.f1 必须始终为 8 */
       T2 f2;
   } T;

3.8. 变体

已定义的结构可以根据环境中可用的某些信息 具有不同变体。选择器必须是一个枚举 类型，用于定义该结构可能具有的变体。select 的每个 分支（见下文）都规定该变体字段的类型以及 可选字段标签。表示语言并未规定 在运行时选择变体的机制。¶

   struct {
       T1 f1;
       T2 f2;
       ....
       Tn fn;
       select (E) {
           case e1: Te1 [[fe1]];
           case e2: Te2 [[fe2]];
           ....
           case en: Ten [[fen]];
       };
   } Tv;

例如：¶

   enum { apple(0), orange(1) } VariantTag;

   struct {
       uint16 number;
       opaque string<0..10>; /* 可变长度 */
   } V1;

   struct {
       uint32 number;
       opaque string[10];    /* 固定长度 */
   } V2;

   struct {
       VariantTag type;
       select (VariantRecord.type) {
           case apple:  V1;
           case orange: V2;
       };
   } VariantRecord;

4.1. 消息记录哈希

TLS 中的许多密码学计算都使用消息记录 哈希。此值通过对每个所包含握手消息的拼接结果进行哈希来计算， 其中包括承载握手消息类型和长度字段的握手 消息标头，但不包括记录层标头。即：¶

 Transcript-Hash(M1, M2, ... Mn) = Hash(M1 || M2 || ... || Mn)

作为这项一般规则的例外，当服务器以 HelloRetryRequest 响应 ClientHello 时，ClientHello1 的值会 替换为一个握手类型为“message_hash”（254）的特殊合成握手消息， 其中包含 Hash(ClientHello1)。即：¶

 Transcript-Hash(ClientHello1, HelloRetryRequest, ... Mn) =
     Hash(message_hash ||        /* 握手类型 */
          00 00 Hash.length  ||  /* 握手消息长度（字节） */
          Hash(ClientHello1) ||  /* ClientHello1 的哈希 */
          HelloRetryRequest  || ... || Mn)

这样构造是为了使服务器能够执行 无状态 HelloRetryRequest，只需在 cookie 中存储 ClientHello1 的哈希， 而不必导出整个中间 哈希状态（参见第 4.3.2 节）。¶

当使用“...”指定一系列消息时，消息记录哈希 取自主握手期间发送或接收的握手消息序列， 从指定的起始消息开始，到指定的结束消息为止。 在本文档中，它取自以下握手 消息序列（其中一些可能被省略）：ClientHello、HelloRetryRequest、ClientHello、 ServerHello、 EncryptedExtensions、服务器 CertificateRequest、服务器 Certificate、 服务器 CertificateVerify、服务器 Finished、EndOfEarlyData、客户端 Certificate、客户端 CertificateVerify 和客户端 Finished。TLS 扩展可以 添加或移除消息，在这种情况下，消息记录哈希将反映 修改后的序列。¶

一般而言，一旦在 ServerHello 中选定了哈希函数， 实现便可以根据协商的哈希函数维护一个 持续更新的消息记录哈希值来实现消息记录。¶

但请注意，后续的握手后身份验证彼此之间并不 相互包含，只包含截至主 握手结束时的消息。¶

4.2. 密钥交换消息

密钥交换消息用于确定客户端和服务器的安全能力， 并建立共享秘密值，其中包括 用于保护其余握手过程和数据的流量密钥。¶

   uint16 ProtocolVersion;
   opaque Random[32];

   uint8 CipherSuite[2];    /* 密码套件选择器 */

   struct {
       ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
       Random random;
       opaque legacy_session_id<0..32>;
       CipherSuite cipher_suites<2..2^16-2>;
       opaque legacy_compression_methods<1..2^8-1>;
       Extension extensions<7..2^16-1>;
   } ClientHello;

   struct {
       ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
       Random random;
       opaque legacy_session_id_echo<0..32>;
       CipherSuite cipher_suite;
       uint8 legacy_compression_method = 0;
       Extension extensions<6..2^16-1>;
   } ServerHello;

  CF 21 AD 74 E5 9A 61 11 BE 1D 8C 02 1E 65 B8 91
  C2 A2 11 16 7A BB 8C 5E 07 9E 09 E2 C8 A8 33 9C

  44 4F 57 4E 47 52 44 01

  44 4F 57 4E 47 52 44 00

4.3. 扩展

许多 TLS 消息包含采用“标记-长度-值”编码的扩展 结构。¶

   struct {
       ExtensionType extension_type;
       opaque extension_data<0..2^16-1>;
   } Extension;

   enum {
       server_name(0),                             /* RFC 6066, 9261 */
       status_request(5),                          /* RFC 6066, 9846 */
       supported_groups(10),                       /* RFC 7919, 9846 */
       signature_algorithms(13),                   /* RFC 9846 */
       use_srtp(14),                               /* RFC 5764 */
       heartbeat(15),                              /* RFC 6520 */
       application_layer_protocol_negotiation(16), /* RFC 7301 */
       client_certificate_type(19),                /* RFC 7250 */
       server_certificate_type(20),                /* RFC 7250 */
       padding(21),                                /* RFC 7685 */
       compress_certificate(27),                   /* RFC 8879 */
       record_size_limit(28),                      /* RFC 8449 */
       delegated_credential(34),                   /* RFC 9345 */
       supported_ekt_ciphers(39),                  /* RFC 8870 */
       pre_shared_key(41),                         /* RFC 9846 */
       early_data(42),                             /* RFC 9846 */
       supported_versions(43),                     /* RFC 9846 */
       cookie(44),                                 /* RFC 9846 */
       psk_key_exchange_modes(45),                 /* RFC 9846 */
       certificate_authorities(47),                /* RFC 9846 */
       oid_filters(48),                            /* RFC 9846 */
       post_handshake_auth(49),                    /* RFC 9846 */
       signature_algorithms_cert(50),              /* RFC 9846 */
       key_share(51),                              /* RFC 9846 */
       transparency_info(52),                      /* RFC 9162 */
       external_id_hash(55),                       /* RFC 8844 */
       external_session_id(56),                    /* RFC 8844 */
       quic_transport_parameters(57),              /* RFC 9001 */
       ticket_request(58),                         /* RFC 9149 */
       ech_outer_extensions(64768),                /* RFC 9849 */
       encrypted_client_hello(65037),              /* RFC 9849 */
       (65535)
   } ExtensionType;

注意：此列表仅包含本文撰写时标记为 “建议”且允许用于 TLS 1.3 的扩展。¶

其中：¶

• “extension_type”标识特定扩展类型。¶

• “extension_data”包含特定扩展类型专用的信息。¶

“extension_data”字段的内容通常由使用 TLS 表示语言定义的 扩展专用结构规定。除非另有规定，否则禁止尾随数据。 也就是说，发送方不得 在“extension_data”字段中的结构之后包含数据。 处理扩展时，如果解析结构后仍有剩余数据， 接收方必须使用“decode_error”警报中止握手。 如果接收方未实现某个扩展，或被配置为忽略该扩展， 则此要求不适用。¶

扩展类型列表由 IANA 按照 第 11 节所述方式维护。¶

扩展通常采用请求/响应形式， 但某些扩展只有请求而没有对应的 响应（即指示）。客户端在 ClientHello 消息中发送扩展请求， 服务器则在 ServerHello、EncryptedExtensions、HelloRetryRequest 和 Certificate 消息中发送扩展响应。服务器在 CertificateRequest 消息中发送扩展请求，客户端可以在 Certificate 消息中作出响应。服务器还可以在 NewSessionTicket 中主动发送扩展，但客户端不会直接 对其作出响应。¶

如果远程端点未发送对应的扩展请求，实现不得 发送扩展响应（即在 ServerHello、EncryptedExtensions、HelloRetryRequest 和 Certificate 消息中）， 但 HelloRetryRequest 中的“cookie”扩展除外。 收到此类扩展时，端点必须使用 “unsupported_extension”警报中止握手。¶

下表指明给定扩展可以出现在哪些消息中， 使用以下记法：CH（ClientHello）、SH （ServerHello）、EE（EncryptedExtensions）、CT（Certificate）、CR （CertificateRequest）、NST（NewSessionTicket）和 HRR （HelloRetryRequest）。如果实现收到它能够识别、但并未规定可用于当前消息的扩展， 则必须使用“illegal_parameter”警报中止握手。¶

注意：此表仅包含本文撰写时标记为 “建议”且允许用于 TLS 1.3 的扩展。¶

存在多个不同类型的扩展时，扩展可以按任意顺序出现， 但“pre_shared_key”（第 4.3.11 节）除外，该扩展必须是 ClientHello 中的最后一个扩展（但可以出现在 ServerHello 扩展块中的任意位置）。 给定扩展块中不得包含多个相同类型的扩展。¶

在 TLS 1.3 中，与 TLS 1.2 不同，即使处于恢复 PSK 模式， 每次握手也会重新协商扩展。但是，0-RTT 参数 是在先前握手中协商的参数；不匹配可能要求 拒绝 0-RTT（参见第 4.3.10 节）。¶

新功能与现有功能之间可能在此协议中发生微妙 （或并不微妙）的交互，从而导致整体安全性 显著降低。设计新扩展时应考虑以下事项：¶

• 服务器不同意扩展的某些情况属于错误 条件（例如握手无法继续），另一些情况 只是拒绝支持特定功能。通常， 前一种情况应使用错误警报，后一种情况则应在服务器 扩展响应中使用字段表示。¶

• 扩展应尽可能设计为防止任何通过操纵握手 消息来强制使用（或不使用）某项特定功能的攻击。 无论是否认为该功能会造成安全问题，都应遵循此原则。 通常，将扩展字段包含在 Finished 消息哈希的输入中便已足够， 但当扩展改变握手阶段所发送消息的含义时， 必须格外谨慎。 设计者和实现者应认识到，在握手经过身份验证之前， 主动攻击者可以修改消息，并插入、移除或替换扩展。¶

   struct {
       select (Handshake.msg_type) {
           case client_hello:
                ProtocolVersion versions<2..254>;

           case server_hello: /* 以及 HelloRetryRequest */
                ProtocolVersion selected_version;
       };
   } SupportedVersions;

   struct {
       opaque cookie<1..2^16-1>;
   } Cookie;

   enum {
       /* RSASSA-PKCS1-v1_5 算法 */
       rsa_pkcs1_sha256(0x0401),
       rsa_pkcs1_sha384(0x0501),
       rsa_pkcs1_sha512(0x0601),

       /* ECDSA 算法 */
       ecdsa_secp256r1_sha256(0x0403),
       ecdsa_secp384r1_sha384(0x0503),
       ecdsa_secp521r1_sha512(0x0603),

       /* 公钥 OID 为 rsaEncryption 的 RSASSA-PSS 算法 */
       rsa_pss_rsae_sha256(0x0804),
       rsa_pss_rsae_sha384(0x0805),
       rsa_pss_rsae_sha512(0x0806),

       /* EdDSA 算法 */
       ed25519(0x0807),
       ed448(0x0808),

       /* 公钥 OID 为 RSASSA-PSS 的 RSASSA-PSS 算法 */
       rsa_pss_pss_sha256(0x0809),
       rsa_pss_pss_sha384(0x080a),
       rsa_pss_pss_sha512(0x080b),

       /* 旧式算法 */
       rsa_pkcs1_sha1(0x0201),
       ecdsa_sha1(0x0203),

       /* 预留码位 */
       private_use(0xFE00..0xFFFF),
       (0xFFFF)
   } SignatureScheme;

   struct {
       SignatureScheme supported_signature_algorithms<2..2^16-2>;
   } SignatureSchemeList;

   opaque DistinguishedName<1..2^16-1>;

   struct {
       DistinguishedName authorities<3..2^16-1>;
   } CertificateAuthoritiesExtension;

   struct {
       opaque certificate_extension_oid<1..2^8-1>;
       opaque certificate_extension_values<0..2^16-1>;
   } OIDFilter;

   struct {
       OIDFilter filters<0..2^16-1>;
   } OIDFilterExtension;

   struct {} PostHandshakeAuth;

   enum {

       /* 椭圆曲线组（ECDHE） */
       secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
       x25519(0x001D), x448(0x001E),

       /* 有限域组（DHE） */
       ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
       ffdhe6144(0x0103), ffdhe8192(0x0104),

       /* 预留码位 */
       ffdhe_private_use(0x01FC..0x01FF),
       ecdhe_private_use(0xFE00..0xFEFF),
       (0xFFFF)
   } NamedGroup;

   struct {
       NamedGroup named_group_list<2..2^16-1>;
   } NamedGroupList;

   struct {
       NamedGroup group;
       opaque key_exchange<1..2^16-1>;
   } KeyShareEntry;

   struct {
       KeyShareEntry client_shares<0..2^16-1>;
   } KeyShareClientHello;

   struct {
       NamedGroup selected_group;
   } KeyShareHelloRetryRequest;

   struct {
       KeyShareEntry server_share;
   } KeyShareServerHello;

   struct {
       uint8 legacy_form = 4;
       opaque X[coordinate_length];
       opaque Y[coordinate_length];
   } UncompressedPointRepresentation;

   enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;

   struct {
       PskKeyExchangeMode ke_modes<1..255>;
   } PskKeyExchangeModes;

   struct {} Empty;

   struct {
       select (Handshake.msg_type) {
           case new_session_ticket:   uint32 max_early_data_size;
           case client_hello:         Empty;
           case encrypted_extensions: Empty;
       };
   } EarlyDataIndication;

   struct {
       opaque identity<1..2^16-1>;
       uint32 obfuscated_ticket_age;
   } PskIdentity;

   opaque PskBinderEntry<32..255>;

   struct {
       PskIdentity identities<7..2^16-1>;
       PskBinderEntry binders<33..2^16-1>;
   } OfferedPsks;

   struct {
       select (Handshake.msg_type) {
           case client_hello: OfferedPsks;
           case server_hello: uint16 selected_identity;
       };
   } PreSharedKeyExtension;

   Transcript-Hash(Truncate(ClientHello1))

   Transcript-Hash(ClientHello1,
                   HelloRetryRequest,
                   Truncate(ClientHello2))

4.4. 服务器参数

服务器接下来发送的两条消息 EncryptedExtensions 和 CertificateRequest 包含来自服务器的信息， 这些信息决定握手的其余部分。这些消息 使用从 server_handshake_traffic_secret 派生的密钥加密。¶

   struct {
       Extension extensions<0..2^16-1>;
   } EncryptedExtensions;

   struct {
       opaque certificate_request_context<0..2^8-1>;
       Extension extensions<0..2^16-1>;
   } CertificateRequest;

4.5. 身份验证 消息

如第 2 节所述，TLS 通常使用一组通用消息 进行身份验证、密钥确认和握手完整性保护： Certificate、CertificateVerify 和 Finished。 （PSK 绑定器也以类似方式执行密钥确认。） 这三条消息始终作为其握手消息批次中的最后几条消息发送。 Certificate 和 CertificateVerify 消息只在下文定义的特定情况下发送。 Finished 消息始终作为身份验证块的一部分发送。 除握手后身份验证外，这些消息使用从 [sender]_handshake_traffic_secret 派生的密钥加密。¶

身份验证消息的所有计算统一采用以下输入：¶

• 要使用的证书和签名密钥。¶

• 由要包含在消息记录哈希中的消息列表组成的握手上下文。¶

• 用于计算 MAC 密钥的基础密钥。¶

基于这些输入，各消息包含以下内容：¶

Certificate：

用于身份验证的证书，以及证书链中的任何 支持证书。请注意，基于证书的客户端身份验证 不可用于 PSK 握手流程（包括 0-RTT）。¶

CertificateVerify：

对值 Transcript-Hash(Handshake Context, Certificate) 的签名。¶

Finished：

使用从基础密钥派生的 MAC 密钥， 对值 Transcript-Hash(Handshake Context, Certificate, CertificateVerify) 计算的 MAC。¶

下表定义每种场景的握手上下文和 MAC 基础密钥：¶

       enum {
           X509(0),
           RawPublicKey(2),
           (255)
       } CertificateType;

       struct {
           select (certificate_type) {
               case RawPublicKey:
                 /* 来自 RFC 7250 的 ASN.1_subjectPublicKeyInfo */
                 opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;

               case X509:
                 opaque cert_data<1..2^24-1>;
           };
           Extension extensions<0..2^16-1>;
       } CertificateEntry;

       struct {
           opaque certificate_request_context<0..2^8-1>;
           CertificateEntry certificate_list<0..2^24-1>;
       } Certificate;

   struct {
       SignatureScheme algorithm;
       opaque signature<0..2^16-1>;
   } CertificateVerify;

   Transcript-Hash(Handshake Context, Certificate)

   2020202020202020202020202020202020202020202020202020202020202020
   2020202020202020202020202020202020202020202020202020202020202020
   544c5320312e332c207365727665722043657274696669636174655665726966
   79
   00
   0101010101010101010101010101010101010101010101010101010101010101

finished_key =
    HKDF-Expand-Label(BaseKey, "finished", "", Hash.length)

   struct {
       opaque verify_data[Hash.length];
   } Finished;

   verify_data =
       HMAC(finished_key,
            Transcript-Hash(Handshake Context,
                            Certificate*, CertificateVerify*))

4.6. 早期数据结束

   struct {} EndOfEarlyData;

如果服务器在 EncryptedExtensions 中发送了 "early_data" 扩展， 客户端在收到服务器 Finished 后必须发送 EndOfEarlyData 消息。如果服务器未在 EncryptedExtensions 中 发送 "early_data" 扩展，则客户端不得发送 EndOfEarlyData 消息。此消息指明所有 0-RTT application_data 消息（如果有）均已传输， 并且后续记录使用握手流量密钥进行保护。 服务器不得发送此消息，收到此消息的客户端 必须使用 "unexpected_message" 警报终止连接。 此消息使用从 client_early_traffic_secret 派生的密钥加密。¶

4.7. 握手后 消息

TLS 还允许在主握手之后发送其他消息。 这些消息使用握手内容类型，并使用 适当的应用流量密钥加密。¶

   struct {
       uint32 ticket_lifetime;
       uint32 ticket_age_add;
       opaque ticket_nonce<0..255>;
       opaque ticket<1..2^16-1>;
       Extension extensions<0..2^16-1>;
   } NewSessionTicket;

    HKDF-Expand-Label(resumption_secret,
                      "resumption", ticket_nonce, Hash.length)

   enum {
       update_not_requested(0), update_requested(1), (255)
   } KeyUpdateRequest;

   struct {
       KeyUpdateRequest request_update;
   } KeyUpdate;

5.1. 记录层

记录层将信息块分割成 TLSPlaintext 记录，每块携带 2¹⁴ 字节或更少的数据。根据底层 ContentType 的不同，消息边界的处理方式也不同。 任何未来的内容类型必须规定适当的规则。 请注意，这些规则比 TLS 1.2 中强制执行的规则更严格。¶

握手消息可以合并到单个 TLSPlaintext 记录中，也可以分割到多个记录中，前提是：¶

• 握手消息不得与其他记录 类型交错。也就是说，如果一条握手消息被分割到两个或多个 记录中，则这些记录之间不得存在任何其他记录。¶

• 握手消息不得跨越密钥 更改。实现必须验证 密钥更改前紧邻的所有消息均与记录边界对齐； 否则，必须使用 “unexpected_message”警报终止连接。 由于 ClientHello、EndOfEarlyData、ServerHello、Finished 和 KeyUpdate 消息可能紧邻密钥更改之前，因此实现必须 发送与记录边界对齐的这些消息。¶

实现不得发送长度为零的 Handshake 类型片段，即使这些片段包含填充。¶

警报消息（第 6 节）不得跨记录分割， 并且多条警报消息不得合并到单个 TLSPlaintext 记录中。换言之，Alert 类型的记录必须恰好包含一条消息。¶

应用数据消息包含对 TLS 不透明的数据。 应用数据消息始终受到保护。可以发送长度为零的 应用数据片段（即内容长度为零且类型为 application_data 的 TLSInnerPlaintext 记录），因为它们可能 可用作对抗流量分析的措施。应用数据片段 可以分割到多个记录中，也可以合并到单个记录中。¶

   enum {
       invalid(0),
       change_cipher_spec(20),
       alert(21),
       handshake(22),
       application_data(23),
       (255)
   } ContentType;

   struct {
       ContentType type;
       ProtocolVersion legacy_record_version;
       uint16 length;
       opaque fragment[TLSPlaintext.length];
   } TLSPlaintext;

type：

用于处理所含片段的更高层协议。¶

legacy_record_version：

除初始 ClientHello （即并非在 HelloRetryRequest 之后生成的 ClientHello）之外， TLS 1.3 实现生成的所有记录都必须将此字段设置为 0x0303； 对于初始 ClientHello，出于兼容性目的， 此字段也可以为 0x0301。 此字段已被弃用，并且在所有情况下都必须忽略。 早期 TLS 版本在某些情况下会在此字段中使用其他值。¶

length：

后续 TLSPlaintext.fragment 的长度（以字节为单位）。 该长度不得超过 2¹⁴ 字节。 收到超过此长度的记录的端点必须使用 “record_overflow”警报终止连接。¶

fragment

正在传输的数据。此值是透明的，并被视为 一个独立的数据块，由 type 字段指定的 更高层协议进行处理。¶

本文档描述使用版本值 0x0304 的 TLS 1.3。 此版本值是历史遗留的，源于 TLS 1.0 使用 0x0301， SSL 3.0 使用 0x0300。为最大限度提高向后 兼容性，包含初始 ClientHello 的记录应使用版本 0x0301（表示 TLS 1.0），而包含第二个 ClientHello 或 ServerHello 的记录必须使用版本 0x0303（表示 TLS 1.2）。 协商早期 TLS 版本时，端点遵循附录 E中提供的流程和要求。¶

在记录保护尚未启用时，TLSPlaintext 结构会直接写入线路。一旦记录保护 开始，TLSPlaintext 记录便按照下一节所述方式 受到保护并发送。请注意，应用数据 记录不得在不受保护的情况下写入线路 （有关详细信息，请参阅第 2 节）。¶

5.2. 记录载荷 保护

记录保护函数将 TLSPlaintext 结构转换为 TLSCiphertext 结构。解除保护函数则执行相反的过程。在 TLS 1.3 中， 与早期 TLS 版本不同，所有密码均建模为 “带关联数据的认证加密”（AEAD）[RFC5116]。 AEAD 函数提供统一的加密和身份验证 操作，将明文转换为经身份验证的密文，并可还原。 每条加密记录均由明文标头和随后的加密主体组成， 加密主体本身包含类型和可选填充。¶

   struct {
       opaque content[TLSPlaintext.length];
       ContentType type;
       uint8 zeros[length_of_padding];
   } TLSInnerPlaintext;

   struct {
       ContentType opaque_type = application_data; /* 23 */
       ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
       uint16 length;
       opaque encrypted_record[TLSCiphertext.length];
   } TLSCiphertext;

content：

TLSPlaintext.fragment 值，其中包含握手消息或 警报消息的字节编码，或者待发送应用数据的 原始字节。¶

type：

包含记录内容类型的 TLSPlaintext.type 值。¶

zeros：

在明文中的 type 字段之后，可以出现任意长度的 零值字节序列。只要总大小仍在记录大小限制以内， 这便使发送方有机会按所选大小填充任何 TLS 记录。 有关更多详细信息，请参阅 第 5.4 节。¶

opaque_type：

TLSCiphertext 记录的外部 opaque_type 字段始终 设置为值 23（application_data），以便在外部与 习惯解析早期 TLS 版本的中间盒兼容。 解密后，可在 TLSInnerPlaintext.type 中找到记录的 实际内容类型。¶

legacy_record_version：

legacy_record_version 字段始终为 0x0303。 TLS 1.3 TLSCiphertext 直到 TLS 1.3 协商完成后才会生成， 因此不存在可能收到其他值的历史兼容性问题。 请注意，握手协议（包括 ClientHello 和 ServerHello 消息） 会验证协议版本，因此此值是冗余的。¶

length：

后续 TLSCiphertext.encrypted_record 的长度 （以字节为单位），它等于内容和填充的长度之和， 再加上内部内容类型所占的一个字节， 以及 AEAD 算法添加的任何扩展。 该长度不得超过 2¹⁴ + 256 字节。 收到超过此长度的记录的端点必须 使用“record_overflow”警报终止连接。¶

encrypted_record：

序列化 TLSInnerPlaintext 结构经 AEAD 加密后的形式。¶

AEAD 算法接收单个密钥、nonce、明文以及 要包含在身份验证检查中的“附加 数据”作为输入，如 [RFC5116] 第 2.1 节所述。 密钥为 client_write_key 或 server_write_key， nonce 从序列号和 client_write_iv 或 server_write_iv 派生（参见第 5.3 节）， 附加数据输入则为记录标头。即：¶

   additional_data = TLSCiphertext.opaque_type ||
                     TLSCiphertext.legacy_record_version ||
                     TLSCiphertext.length

AEAD 算法的明文输入为编码后的 TLSInnerPlaintext 结构。 流量密钥的派生定义于第 7.3 节。¶

AEAD 输出由 AEAD 加密操作产生的密文组成。 由于包含 TLSInnerPlaintext.type 和发送方提供的任何填充， 明文长度大于对应的 TLSPlaintext.length。 AEAD 输出的长度通常会大于明文， 但增加量会因 AEAD 算法而异。由于密码可能 包含填充，因此开销可能随明文长度不同而变化。 用符号表示为：¶

   AEADEncrypted =
       AEAD-Encrypt(write_key, nonce, additional_data, plaintext)

TLSCiphertext 的 encrypted_record 字段设置为 AEADEncrypted。¶

为进行解密和验证，密码接收密钥、nonce、 附加数据和 AEADEncrypted 值作为输入。输出要么是明文， 要么是表示解密失败的错误。不进行单独的 完整性检查。用符号表示为：¶

 plaintext of encrypted_record =
     AEAD-Decrypt(peer_write_key, nonce, additional_data, AEADEncrypted)

如果解密失败，接收方必须使用 “bad_record_mac”警报终止连接。¶

TLS 1.3 中使用的 AEAD 算法不得产生 超过 255 个八位字节的扩展。端点收到对等方发送的、 TLSCiphertext.length 大于 2¹⁴ + 256 个八位字节的记录时，必须 使用“record_overflow”警报终止连接。 此限制源于 TLSInnerPlaintext 的最大长度： 2¹⁴ 个八位字节，加上 ContentType 的 1 个八位字节， 再加上 AEAD 最大扩展的 255 个八位字节。¶

5.3. 逐记录 nonce

读取和写入记录分别维护一个 64 位序列号。 每读取或写入一条记录后，相应序列号递增一。 每个序列号在连接开始时以及每次密钥更改时均设置为零； 使用特定流量密钥传输的第一条记录必须使用 序列号 0。¶

由于序列号大小为 64 位，因此不应 发生回绕。如果 TLS 实现需要 使序列号回绕，则必须重新生成密钥 （第 4.7.3 节） 或终止连接。¶

每种 AEAD 算法都会为逐记录 nonce 指定一个可能的输入长度范围，从 N_MIN 字节到 N_MAX 字节 [RFC5116]。 TLS 逐记录 nonce 的长度（iv_length）设置为 8 字节与 AEAD 算法的 N_MIN 两者中的较大值 （参见 [RFC5116] 的第 4 节）。 N_MAX 小于 8 字节的 AEAD 算法不得与 TLS 一起使用。 AEAD 构造的逐记录 nonce 按以下方式形成：¶

1. 将 64 位记录序列号按网络字节序编码， 并在左侧填充零，直至达到 iv_length。¶

2. 将填充后的序列号与静态 client_write_iv 或 server_write_iv（取决于角色） 进行 XOR 运算。¶

所得值（长度为 iv_length）用作逐记录 nonce。¶

注意：此构造与 TLS 1.2 中的构造不同， 后者规定了部分显式的 nonce。¶

5.4. 记录填充

所有加密的 TLS 记录都可以进行填充，以增大 TLSCiphertext 的大小。这使发送方能够向观察者隐藏 流量大小。¶

生成 TLSCiphertext 记录时，实现可以选择进行填充。 未填充记录就是填充长度为零的记录。 填充是在加密前附加到 ContentType 字段之后的一串零值字节。实现必须在加密前 将所有填充八位字节设置为零。¶

如果发送方希望，应用数据记录可以包含长度为零的 TLSInnerPlaintext.content。这允许在活动是否存在 可能属于敏感信息的场景中，生成大小看似合理的掩护 流量。实现不得发送 TLSInnerPlaintext.content 长度为零的 Handshake 和 Alert 记录； 如果收到此类消息，接收实现必须使用 “unexpected_message”警报终止连接。¶

发送的填充由记录保护机制自动验证； 成功解密 TLSCiphertext.encrypted_record 后， 接收实现从字段末尾向 开头扫描，直到找到一个非零八位字节。 此非零八位字节就是消息的内容类型。 选择此填充方案是因为它允许以任意大小 （从零到 TLS 记录大小限制）填充任何加密的 TLS 记录，而无需引入新的内容类型。该设计还 强制要求所有填充八位字节均为零，从而可以快速检测 填充错误。¶

实现必须将扫描限制在 AEAD 解密返回的明文中。如果接收实现未在 明文中找到非零八位字节，则必须使用 “unexpected_message”警报终止连接。¶

填充的存在不会改变总体记录大小限制： 完整编码后的 TLSInnerPlaintext不得超过 2¹⁴ + 1 个八位字节。如果最大片段长度被缩小 ——例如通过 [RFC8449] 中的 record_size_limit 扩展——， 则缩小后的限制适用于完整明文， 包括内容类型和填充。¶

选择用于指明何时填充以及填充多少的填充策略 是一个复杂主题，超出了本规范的范围。如果构建于 TLS 之上的 应用层协议具有自己的填充，则可能更适合 在应用层填充应用数据 TLS 记录。 不过，加密 Handshake 或 Alert 记录的填充仍必须 在 TLS 层处理。后续文档可以定义 填充选择算法，或者通过 TLS 扩展或其他方式定义 填充策略请求机制。¶

5.5. 密钥使用限制

在给定密钥集下可安全加密的明文数量存在 密码学限制。[AEAD-LIMITS] 在假设底层 原语（AES 或 ChaCha20）不存在弱点的情况下分析了这些限制。 实现必须在达到这些限制之前， 关闭连接或按照第 4.7.3 节所述方式执行密钥更新。 请注意，无法对早期数据执行 KeyUpdate； 因此，实现发送早期数据时不得超过这些限制。 接收实现不应强制执行这些限制， 因为未来的分析可能产生更新后的值。¶

对于 AES-GCM，在给定密钥集下最多可以加密 2^24.5 条完整大小的记录（约 2400 万条）， 同时为认证加密（AE）安全性保留约 2^-57 的安全余量。 对于 ChaCha20/Poly1305，在达到安全限制之前， 记录序列号便会回绕。¶

6.1. 关闭警报

为避免截断攻击，客户端和服务器必须共同知晓连接正在 结束。¶

close_notify：

此警报通知接收方，发送方不会再通过此连接 发送任何消息。收到关闭警报后接收的任何数据必须被忽略。 此警报必须以 AlertLevel=warning 发送。¶

user_canceled：

此警报通知接收方，发送方正在因与协议失败无关的 某种原因取消握手。如果用户在握手完成后 取消操作，则发送“close_notify”以直接关闭 连接更为合适。此警报后必须跟随一个“close_notify”。 此警报通常使用 AlertLevel=warning。接收实现应 继续从对等方读取数据，直到收到“close_notify”， 不过它们可以记录日志或以其他方式记录这些数据。¶

任一方可以通过发送“close_notify”警报， 发起关闭连接的写入方向。 如果在“close_notify”之前收到传输层关闭， 接收方将无法知道发送的所有数据是否都已收到。¶

除非已经发送某个错误警报，否则每一方在关闭连接的写入方向之前 必须发送“close_notify”警报。 这不会对连接的读取方向产生任何影响。请注意，这是相对于 TLS 1.3 之前版本的一项更改；在那些版本中，实现收到 “close_notify”后必须丢弃待处理的写入， 并立即发送自己的“close_notify”警报。 之前的要求可能导致读取方向发生截断。 双方在关闭连接的读取方向之前都不必 等待收到“close_notify”警报，不过这样做会引入截断的可能性。¶

应用协议可以选择在收到“close_notify”后刷新其 发送缓冲区并立即发送“close_notify”，但这样会允许攻击者 通过延迟“close_notify”，或延迟在传输层交付应用的数据包， 影响对等方收到的数据。 这些问题可以在应用层解决，例如忽略 发送“close_notify”后收到的数据包。¶

如果使用 TLS 的应用协议允许在 TLS 连接关闭后， 仍通过底层传输承载任何数据，则 TLS 实现在向应用层指明数据结束之前必须收到“close_notify”警报。 不应将本标准的任何部分理解为规定 TLS 使用配置文件 管理其数据传输的方式，包括何时打开或关闭连接。¶

注意：这里假设关闭连接的写入方向时， 会在销毁传输之前可靠地交付待处理数据。¶

6.2. 错误警报

TLS 中的错误处理非常简单。当检测到 错误时，检测到错误的一方向其 对等方发送消息。发送或收到致命警报消息时， 双方必须立即关闭连接。¶

实现遇到致命错误条件时， 应发送适当的致命警报，并且必须关闭连接， 不再发送或接收任何其他数据。在本规范中， 当使用“终止连接”和“中止握手”而未指定具体警报时， 表示实现应发送以下描述中指明的警报。 “使用 X 警报终止连接”和 “使用 X 警报中止握手”表示，如果实现发送任何警报， 则必须发送警报 X。本节下文定义的所有 警报以及所有未知警报，自 TLS 1.3 起都被普遍视为致命警报 （参见第 6 节）。 实现应提供一种方法，以便记录 警报的发送和接收。¶

定义了以下错误警报：¶

unexpected_message：

收到了不适当的消息（例如错误的握手消息、 过早发送的 应用数据等）。在正确实现之间的通信中， 不应观察到此警报。¶

bad_record_mac：

收到无法解除保护的记录时返回此警报。 由于 AEAD 算法将解密和验证合并， 并且为了避免侧信道攻击， 所有解除保护失败都使用此警报。 除非消息在网络中损坏，否则在 正确实现之间的通信中不应观察到此警报。¶

record_overflow：

收到长度超过 2¹⁴ + 256 字节的 TLSCiphertext 记录，或者某条记录解密后得到 超过 2¹⁴ 字节（或其他协商限制）的 TLSPlaintext 记录。 除非消息在网络中损坏，否则在 正确实现之间的通信中不应观察到此警报。¶

handshake_failure：

收到“handshake_failure”警报消息表示， 发送方无法在现有选项中协商出一组可接受的 安全参数。¶

bad_certificate：

证书已损坏、包含无法正确验证的签名等。¶

unsupported_certificate：

证书属于不受支持的类型。¶

certificate_revoked：

证书已被其签名者撤销。¶

certificate_expired：

证书已过期或当前无效。¶

certificate_unknown：

处理证书时出现其他未指定的问题， 导致证书不可接受。¶

illegal_parameter：

握手中的某个字段不正确，或与 其他字段不一致。此警报用于符合 正式协议语法、但在其他方面不正确的错误。¶

unknown_ca：

收到了有效证书链或部分证书链， 但由于无法找到 CA 证书， 或无法将其与已知信任锚匹配，因此未接受该证书。¶

access_denied：

收到了有效证书或 PSK，但应用访问控制后， 发送方决定不继续协商。¶

decode_error：

由于某个字段超出规定范围， 或消息长度不正确，无法解码消息。 此警报用于消息不符合 正式协议语法的错误。 除非消息在网络中损坏，否则在 正确实现之间的通信中不应观察到此警报。¶

decrypt_error：

握手层（而非记录层）的密码学操作失败， 包括无法正确验证签名、验证 Finished 消息 或验证 PSK 绑定器。¶

protocol_version：

对等方尝试协商的协议版本 可以识别，但不受支持（参见附录 E）。¶

insufficient_security：

当协商失败的具体原因是服务器需要的参数 比客户端支持的参数更安全时，返回此警报， 而不是“handshake_failure”。¶

internal_error：

出现与对等方或协议正确性无关的内部错误 （例如内存分配失败），导致无法继续。¶

inappropriate_fallback：

服务器在响应客户端无效的连接重试 尝试时发送此警报（参见 [RFC7507]）。¶

missing_extension：

端点收到的握手消息中缺少 针对所提供 TLS 版本或其他协商参数 必须发送的扩展时，发送此警报。¶

unsupported_extension：

端点收到的握手消息中，ServerHello、 HelloRetryRequest、EncryptedExtensions 或 Certificate 包含 未先在对应 ClientHello 或 CertificateRequest 中提供的扩展时， 发送此警报。¶

unrecognized_name：

客户端通过“server_name”扩展提供的名称 未标识任何现有服务器时，由服务器发送此警报 （参见 [RFC6066]）。¶

bad_certificate_status_response：

服务器通过“status_request”扩展提供 无效或不可接受的 OCSP 响应时，由客户端发送此警报 （参见 [RFC6066]）。¶

unknown_psk_identity：

希望进行 PSK 密钥建立，但客户端未提供 可接受的 PSK 身份时，由服务器发送此警报。 发送此警报是可选的；服务器也可以选择发送 “decrypt_error”警报，仅用于指明 PSK 身份无效。¶

certificate_required：

服务器需要客户端证书， 但客户端未提供时，由服务器发送此警报。¶

general_error：

在没有更具体的错误可用， 或发送方希望隐藏具体错误代码时， 发送此警报以指明错误条件。存在更具体错误时，实现应使用 更具体的错误。¶

no_application_protocol：

客户端 “application_layer_protocol_negotiation”扩展只公布 服务器不支持的协议时，由服务器发送此警报 （参见 [RFC7301]）。¶

新的 Alert 值由 IANA 按照第 11 节所述方式分配。¶

7.1. 密钥调度

密钥派生过程使用为 HKDF [RFC5869] 定义的 HKDF-Extract 和 HKDF-Expand 函数，以及下文定义的函数：¶

    HKDF-Expand-Label(Secret, Label, Context, Length) =
         HKDF-Expand(Secret, HkdfLabel, Length)

其中 HkdfLabel 规定如下：¶

    struct {
        uint16 length = Length;
        opaque label<7..255> = "tls13 " + Label;
        opaque context<0..255> = Context;
    } HkdfLabel;

    Derive-Secret(Secret, Label, Messages) =
         HKDF-Expand-Label(Secret, Label,
                           Transcript-Hash(Messages), Hash.length)

Transcript-Hash 和 HKDF 使用的 Hash 函数是密码套件的 哈希算法。 Hash.length 是其输出长度，以字节为单位。Messages 是所指明 握手消息的拼接结果，包括握手消息类型 和长度字段，但不包括记录层标头。请注意， 在某些情况下，会向 HKDF-Expand-Label 传递 长度为零的 Context（以“”表示）。 本文档规定的标签均为 ASCII 字符串， 且不包含尾随 NUL 字节。¶

使用“HKDF-Expand-Label”的任何 TLS 扩展， 都使用与其所用 TLS 版本关联的 HkdfLabel 定义。 与本规范一起使用时，这意味着 使用上文定义的 HkdfLabel；与 DTLS [RFC9147] 一起使用时， 则意味着使用 [RFC9147] 的第 5.9 节中定义的版本。¶

注意：使用常见哈希函数时，长度超过 12 个字符的任何标签 都需要额外迭代一次哈希函数进行计算。 本规范中的所有标签均已选择为不超过 此限制。¶

密钥通过 HKDF-Extract 和 Derive-Secret 函数， 从两个输入秘密值派生。添加新秘密值的一般模式 是使用 HKDF-Extract，将 Salt 设为当前秘密状态，将输入密钥材料（IKM）设为要添加的 新秘密值。在此 TLS 1.3 版本中，两个 输入秘密值为：¶

• PSK（外部建立的预共享密钥， 或从先前连接的 resumption_secret 值派生的密钥）¶

• 非对称密钥建立产生的非对称共享秘密值 （参见第 7.4 节）¶

这将生成下图所示的密钥调度 （图 5）。 在此图中，采用以下格式约定：¶

• HKDF-Extract 绘制为从上方接收 Salt 参数， 从左侧接收 IKM 参数，其输出位于下方， 输出名称位于右侧。¶

• Derive-Secret 的 Secret 参数由入向箭头指明。 例如，Early Secret 是用于生成 client_early_traffic_secret 的 Secret。¶

• “0”表示由 Hash.length 个值为零的字节组成的字符串。¶

注意：即使这些值被称为“main”秘密值， 密钥派生标签仍使用字符串“master”。这种不一致 是在保留兼容性的同时重命名这些值所造成的结果。¶

注意：此图并未显示所有叶子密钥，例如单独的 AEAD 密钥和 IV 密钥，而只显示从握手中派生的 第一组秘密值。¶

                 0
                 |
                 v
     PSK -->  HKDF-Extract = 早期秘密值
                 |
                 +-----> Derive-Secret(.,
                 |                     "ext binder" |
                 |                     "res binder",
                 |                     "")
                 |              = binder_key
                 |
                 +-----> Derive-Secret(., "c e traffic",
                 |                     ClientHello)
                 |              = client_early_traffic_secret
                 |
                 +-----> Derive-Secret(., "e exp master",
                 |                     ClientHello)
                 |              = early_exporter_secret
                 v
            Derive-Secret(., "derived", "")
                 |
    非对称       v
  共享秘密值 --> HKDF-Extract = 握手秘密值
                 |
                 +-----> Derive-Secret(., "c hs traffic",
                 |                     ClientHello...ServerHello)
                 |              = client_handshake_traffic_secret
                 |
                 +-----> Derive-Secret(., "s hs traffic",
                 |                     ClientHello...ServerHello)
                 |              = server_handshake_traffic_secret
                 v
            Derive-Secret(., "derived", "")
                 |
                 v
        0 --> HKDF-Extract = 主秘密值
                 |
                 +-----> Derive-Secret(., "c ap traffic",
                 |                     ClientHello...server Finished)
                 |              = client_application_traffic_secret_0
                 |
                 +-----> Derive-Secret(., "s ap traffic",
                 |                     ClientHello...server Finished)
                 |              = server_application_traffic_secret_0
                 |
                 +-----> Derive-Secret(., "exp master",
                 |                     ClientHello...server Finished)
                 |              = exporter_secret
                 |
                 +-----> Derive-Secret(., "res master",
                                       ClientHello...client Finished)
                                = resumption_secret

这里的一般模式是，图左侧所示的秘密值 只是没有上下文的原始熵，而右侧的 秘密值包含握手上下文，因此 无需附加上下文即可用于派生工作密钥。 请注意，即使使用相同秘密值，对 Derive-Secret 的不同 调用也可以采用不同的 Messages 参数。 在 0-RTT 交换中，Derive-Secret 使用四个不同的消息记录调用； 在仅使用 1-RTT 的交换中， 则使用三个不同的消息记录调用。¶

如果某个秘密值不可用，则使用由 Hash.length 个值为零的字节组成的 0 值。请注意，这并不表示跳过 轮次，因此如果未使用 PSK，Early Secret 仍然是 HKDF-Extract(0, 0)。计算 binder_key 时， 外部 PSK（在 TLS 之外配置的 PSK）使用标签 “ext binder”，恢复 PSK（作为先前握手恢复秘密值配置的 PSK） 使用“res binder”。不同标签可防止 将一种 PSK 替换为另一种。¶

根据服务器最终选择的 PSK，可能存在多个 Early Secret 值。客户端需要为每个可能的 PSK 计算 一个值；如果未选择任何 PSK，则还需要 计算与零 PSK 对应的 Early Secret。¶

从某个给定秘密值派生的所有值 计算完成后，该秘密值应被清除。¶

7.2. 更新流量 秘密值

握手完成后，任一方都可以使用 第 4.7.3 节中定义的 KeyUpdate 握手消息更新其发送流量密钥。下一代流量密钥通过以下方式计算： 按本节所述，从 client_/server_application_traffic_secret_N 生成 client_/server_application_traffic_secret_N+1， 然后按照第 7.3 节所述重新派生流量密钥。¶

下一代 application_traffic_secret 按以下方式计算：¶

    application_traffic_secret_N+1 =
        HKDF-Expand-Label(application_traffic_secret_N,
                          "traffic upd", "", Hash.length)

计算出 client_/server_application_traffic_secret_N+1 及其关联流量密钥后，实现应删除 client_/server_application_traffic_secret_N 及其关联流量密钥。¶

7.3. 流量密钥 计算

流量密钥材料由以下输入值生成：¶

• 秘密值¶

• 指明正在生成的具体值的用途值¶

• 正在生成的密钥长度¶

流量密钥材料通过以下方式从输入流量秘密值生成：¶

[sender]_write_key = HKDF-Expand-Label(Secret, "key", "", key_length)
[sender]_write_iv  = HKDF-Expand-Label(Secret, "iv", "", iv_length)

[sender] 表示发送方。每种数据类别的 Secret 值 如下表所示。¶

警报使用发送时的当前发送密钥发送 （如果尚未建立此类密钥，则以明文发送）。 每当底层 Secret 发生变化时，都会重新计算所有流量密钥材料 （例如从握手密钥切换到应用数据密钥， 或执行密钥更新时）。¶

7.4. 非对称共享 秘密值计算

7.5. 导出器

[RFC5705] 使用 TLS 伪随机函数（PRF）定义了 TLS 密钥材料导出器。 本文档以 HKDF 替代 PRF，因此 需要一种新构造。导出器接口保持不变。¶

导出器值按以下方式计算：¶

TLS-Exporter(label, context_value, key_length) =
    HKDF-Expand-Label(Derive-Secret(Secret, label, ""),
                      "exporter", Hash(context_value), key_length)

其中 Secret 为 early_exporter_secret 或 exporter_secret。除非应用明确指定，否则实现必须使用 exporter_secret。early_exporter_secret 定义用于 0-RTT 数据需要导出器的场景。 建议为早期导出器提供单独接口； 这样可以避免导出器用户在需要常规导出器时 意外使用早期导出器，反之亦然。¶

如果未提供上下文，则 context_value 长度为零。 因此，不提供上下文与提供空上下文计算得到相同的值。 这不同于早期 TLS 版本；在那些版本中，空上下文产生的 输出不同于缺少上下文的情况。截至本文档发布时， 没有任何已分配导出器标签同时在有上下文和无上下文的情况下使用。 未来规范不得定义允许同一标签同时使用空上下文 和无上下文的导出器用法。导出器的新用法应在所有导出器计算中提供 上下文，不过该值可以为空。¶

导出器标签格式的要求定义于 [RFC5705] 第 4 节。¶

8.1. 一次性票据

最简单的抗重放防御形式，是服务器只允许 每个会话票据使用一次。例如，服务器 可以维护所有尚未使用的有效票据的数据库，并在每个 票据使用时将其从数据库中删除。如果提供未知票据， 服务器随后会回退到完整握手。¶

如果票据并非自包含，而是数据库键， 并且对应 PSK 在使用后被删除，则使用 PSK 建立的连接 不仅具有抗重放保护，而且在数据库条目中的所有 PSK 副本 均被删除后还具有前向保密性。 当 PSK 在不使用非对称密钥交换的情况下使用时， 此机制也能增强 PSK 使用的安全性。¶

由于此机制要求在具有多个分布式服务器的环境中 在服务器节点之间共享会话数据库， 与自行加密的票据相比，可能很难实现较高比例的 成功 PSK 0-RTT 连接。 与会话数据库不同，即使没有一致存储， 会话票据仍可成功进行基于 PSK 的会话建立； 不过当允许 0-RTT 时，它们仍需要一致存储， 以对 0-RTT 数据实施抗重放保护， 具体见下一节。¶

8.2. 记录客户端问候

另一种抗重放形式是记录从 ClientHello 派生的唯一值 （通常是随机值或 PSK 绑定器），并拒绝重复项。记录所有 ClientHello 会导致状态 无界增长，但服务器可以改为记录给定时间窗口内的 ClientHello， 并使用“obfuscated_ticket_age”确保票据不会在该窗口之外复用。¶

为实现此机制，收到 ClientHello 时，服务器 首先按照第 4.3.11 节所述验证 PSK 绑定器。 随后按下一节所述计算 expected_arrival_time；如果该时间不在记录窗口内， 则拒绝 0-RTT，并回退到 1-RTT 握手。¶

如果 expected_arrival_time 位于窗口内， 服务器就检查是否已记录匹配的 ClientHello。如果找到， 则使用“illegal_parameter”警报中止握手， 或接受 PSK 但拒绝 0-RTT。如果未找到匹配的 ClientHello， 则接受 0-RTT，并在 expected_arrival_time 仍位于窗口内期间存储该 ClientHello。 服务器也可以实现存在误报的数据存储，例如 Bloom 过滤器；在这种情况下，对于表面上的重放， 服务器必须拒绝 0-RTT，但不得中止握手。¶

服务器必须只从 ClientHello 中经过验证的部分 派生存储键。如果 ClientHello 包含多个 PSK 身份， 攻击者可以为偏好较低的身份创建具有不同绑定器值的多个 ClientHello， 并假设服务器不会验证该绑定器 （如第 4.3.11 节所建议）。 也就是说，如果客户端发送 PSK A 和 B，但服务器偏好 A， 攻击者可以更改 B 的绑定器，而不影响 A 的绑定器。如果 B 的绑定器是存储键的一部分， 则此 ClientHello 不会显示为重复项， 从而导致该 ClientHello 被接受，并可能 引发诸如重放缓存污染之类的副作用； 不过任何 0-RTT 数据都无法解密， 因为它将使用不同的密钥。 如果使用经过验证的绑定器或 ClientHello.random 作为存储键， 则无法实施此攻击。¶

由于此机制不需要存储所有尚未使用的票据， 因而可能更容易在具有高恢复率和高 0-RTT 使用率的 分布式系统中实现；代价是，由于难以可靠地 存储和检索收到的 ClientHello 消息， 抗重放防御可能较弱。 在许多此类系统中，对所有收到的 ClientHello 进行全局一致存储并不现实。 在这种情况下，最佳抗重放保护是 让单个存储区域对给定票据具有权威性， 并在任何其他区域拒绝该票据的 0-RTT。 这种方法可以防止攻击者进行简单重放， 因为只有一个区域会接受 0-RTT 数据。 较弱的设计是为每个区域实现独立存储， 但允许任何区域接受 0-RTT。 此方法将重放次数限制为每个区域一次。 当然，无论采用哪种设计，应用消息重复仍然可能发生。¶

实现刚启动时，只要其记录窗口的任何部分 与启动时间重叠，就应 拒绝 0-RTT。否则，它们可能接受 最初在该时间段内发送的重放消息。¶

注意：如果客户端时钟运行速度远快于服务器时钟， 则收到的 ClientHello 可能位于窗口未来一侧之外； 在这种情况下，它可能被接受用于 1-RTT，从而导致客户端重试， 随后又在稍后变得可接受用于 0-RTT。 这是第 8 节所述第二类攻击的另一种变体。¶

8.3. 新鲜度检查

由于 ClientHello 指明客户端发送它的时间， 因此可以高效判断 ClientHello 是否很可能在合理的近期发送， 并且只对此类 ClientHello 接受 0-RTT； 否则回退到 1-RTT 握手。 这对于第 8.2 节所述的 ClientHello 存储机制是必要的， 因为否则服务器需要存储无限数量的 ClientHello； 对于自包含的一次性票据，这也是一种有用的优化， 因为它可以高效拒绝无法用于 0-RTT 的 ClientHello。¶

为实现此机制，服务器需要存储 服务器生成会话票据的时间，并加上客户端与服务器之间 往返时间的估计值。即：¶

    adjusted_creation_time = creation_time + estimated_RTT

此值可以编码到票据中，从而无需 为每个尚未使用的票据保留状态。服务器可以通过从客户端 “pre_shared_key”扩展中的“obfuscated_ticket_age”参数减去票据的 “ticket_age_add”值，确定客户端所认为的票据期限。 服务器可以按以下方式确定 ClientHello 的 expected_arrival_time：¶

  expected_arrival_time = adjusted_creation_time + clients_ticket_age

收到新的 ClientHello 时， 将 expected_arrival_time 与服务器当前墙上时钟时间进行比较； 如果二者相差超过某个数值，则拒绝 0-RTT， 不过仍可允许 1-RTT 握手完成。¶

存在若干潜在误差来源，可能导致 expected_arrival_time 与测量时间不匹配。 客户端和服务器时钟速率的变化通常可能很小， 不过绝对时间可能相差很大。 网络传播延迟最有可能导致 合法经过时间值不匹配。NewSessionTicket 和 ClientHello 消息都可能被重新传输， 因而产生延迟，而这种延迟可能被 TCP 隐藏。 对于互联网上的客户端，这意味着窗口 大约需要十秒，以考虑时钟误差和测量变化； 其他部署场景可能具有不同需求。 时钟偏差分布并不对称，因此最佳折衷方案 可能需要采用不对称的允许误差范围。¶

请注意，仅靠新鲜度检查不足以防止重放， 因为它无法检测误差窗口内发生的重放； 根据带宽和系统容量， 现实环境中该窗口内可能包含数十亿次重放。 此外，新鲜度检查只在收到 ClientHello 时执行， 而不会在收到后续早期应用数据记录时执行。 接受早期数据后，记录可能继续以流式方式 发送到服务器，持续更长时间。¶

9.1. 必须实现的 密码套件

在没有应用配置文件标准另有规定的情况下：¶

• 符合 TLS 的应用必须 实现 TLS_AES_128_GCM_SHA256 [GCM] 密码套件，并且应实现 TLS_AES_256_GCM_SHA384 [GCM] 和 TLS_CHACHA20_POLY1305_SHA256 [RFC8439] 密码套件 （参见附录 B.4）。¶

• 符合 TLS 的应用必须支持使用 rsa_pkcs1_sha256（用于证书）、rsa_pss_rsae_sha256（用于 CertificateVerify 和证书）以及 ecdsa_secp256r1_sha256 的数字签名。符合 TLS 的应用必须支持使用 secp256r1（NIST P-256）进行密钥交换， 并且应支持使用 X25519 [RFC7748] 进行密钥交换。¶

9.2. 必须实现的 扩展

在没有应用配置文件标准另有规定的情况下， 符合 TLS 的应用必须实现以下 TLS 扩展：¶

• 支持的版本（“supported_versions”；第 4.3.1 节）¶

• Cookie（“cookie”；第 4.3.2 节）¶

• 签名算法（“signature_algorithms”；第 4.3.3 节）¶

• 证书签名算法（“signature_algorithms_cert”；第 4.3.3 节）¶

• 支持的组（“supported_groups”；第 4.3.7 节）¶

• 密钥共享（“key_share”；第 4.3.8 节）¶

• 服务器名称指示（“server_name”；[RFC6066] 第 3 节）¶

提供适用功能时，所有实现必须发送并使用这些 扩展：¶

• 所有 ClientHello、ServerHello 和 HelloRetryRequest 消息都要求包含“supported_versions”。¶

• 证书身份验证要求使用 “signature_algorithms”。¶

• 使用 DHE 或 ECDHE 密钥交换的 ClientHello 消息要求包含“supported_groups”。¶

• DHE 或 ECDHE 密钥交换要求使用 “key_share”。¶

• PSK 密钥协商要求使用 “pre_shared_key”。¶

• PSK 密钥协商要求使用 “psk_key_exchange_modes”。¶

如果 ClientHello 包含 主体中含 0x0304 的“supported_versions”扩展， 则认为客户端正尝试使用本规范进行协商。 此类 ClientHello 消息必须满足以下要求：¶

• 如果不包含“pre_shared_key”扩展，则必须同时包含 “signature_algorithms”扩展和“supported_groups”扩展。¶

• 如果包含“supported_groups”扩展，则必须同时包含 “key_share”扩展，反之亦然。允许空的 KeyShare.client_shares 列表。¶

服务器收到不符合这些 要求的 ClientHello 时，必须使用“missing_extension” 警报中止握手。¶

此外，所有实现必须支持 能够使用“server_name”扩展的应用使用该扩展。 服务器可以要求客户端发送有效的“server_name”扩展。 要求此扩展的服务器应在收到缺少“server_name”扩展的 ClientHello 时，使用“missing_extension”警报终止连接。¶

9.3. 协议不变量

本节描述 TLS 端点和中间盒必须遵循的不变量。 这些要求也适用于早期 TLS 版本。¶

TLS 的设计目标是能够安全且兼容地扩展。 较新的客户端或服务器在与较新的对等方通信时， 应协商双方共同支持且最为偏好的参数。 TLS 握手提供降级保护：在不终止 TLS 的情况下， 在较新客户端和较新服务器之间转发流量的中间盒 应无法影响握手（参见附录 F.1）。 与此同时，不同部署的更新速率不同， 因而较新的客户端或服务器可以继续支持旧参数， 从而与旧端点互操作。¶

为使此机制正常工作，实现必须正确处理 可扩展字段：¶

• 发送 ClientHello 的客户端必须 支持其中公布的所有非 GREASE [RFC8701] 参数。 否则，服务器可能选择其中一个参数，导致 无法互操作。¶

• 收到 ClientHello 的服务器必须 正确忽略所有无法识别的密码套件、扩展和其他参数。 否则，它可能无法与较新的客户端互操作。 在 TLS 1.3 中，收到 CertificateRequest 或 NewSessionTicket 的客户端 也必须忽略所有无法识别的扩展。¶

• 终止 TLS 连接的中间盒必须充当符合要求的 TLS 服务器（面向原始客户端），包括拥有 客户端愿意接受的证书；同时还必须充当符合要求的 TLS 客户端 （面向原始服务器），包括验证原始服务器的证书。 特别是，它必须生成自己的 ClientHello， 其中只包含它理解的参数，并且必须生成新的 ServerHello 随机值，而不是转发端点的值。¶

  请注意，TLS 的协议要求和安全分析只分别适用于 两个连接。安全部署 TLS 终止器需要 额外的安全考虑，这超出了本文档的范围。¶

• 转发其不理解的 ClientHello 参数的中间盒 不得处理该 ClientHello 之后的任何消息。 它必须原样转发所有后续流量。 否则，它可能无法与较新的客户端和服务器互操作。¶

  被转发的 ClientHello 可能包含中间盒不支持的功能公告， 因此响应可能包含中间盒无法识别的未来 TLS 扩展。 这些扩展可以任意更改 ClientHello 之后的任何消息。 特别是，ServerHello 中发送的值可能发生变化， ServerHello 格式可能发生变化， TLSCiphertext 格式也可能发生变化。¶

TLS 1.3 的设计受到广泛部署但不符合要求的 TLS 中间盒限制（参见附录 E.4）； 但这并不会放宽这些不变量。 这些中间盒仍然不符合要求。¶

11.1. 本 RFC 的变更

IANA 已将 IANA 注册表中对 [RFC8446] 的所有引用 更新为对本文档的引用。¶

IANA 已更新 TLS SignatureScheme 和 PskKeyExchangeMode 注册表的 “Recommended”列流程，使其与 [RFC9847] 保持一致。¶

IANA 已将 TLS ExtensionType Values 注册表中的 “extended_master_secret”值重命名为“extended_main_secret”。¶

IANA 已在 TLS Alerts 注册表中为“general_error” 警报创建一个值，其值采用第 6 节中给出的值。¶

IANA 已为 TLS ExtensionType Values 注册表中的 status_request 和 supported_groups 条目添加对本文档的引用。¶

IANA 已将 cached_info 在“TLS 1.3”列中的 TLS ExtensionType 值 更新为“CH, EE”。¶

12.1. 规范性参考文献

[GCM]

Dworkin, M.，“分组密码工作模式建议： Galois/计数器模式（GCM）和 GMAC”，NIST SP 800-38D，DOI 10.6028/NIST.SP.800-38D，2007 年 11 月，<https://doi.org/10.6028/NIST.SP.800-38D>。

[KEYAGREEMENT]

Barker, E.、Chen, L.、Roginsky, A.、Vassilev, A. 和 R. Davis，“使用离散对数密码学的 成对密钥建立方案建议”，美国国家标准与技术研究院，DOI 10.6028/nist.sp.800-56ar3，2018 年 4 月，<https://doi.org/10.6028/nist.sp.800-56ar3>。

[RFC2104]

Krawczyk, H.、Bellare, M. 和 R. Canetti，“HMAC：用于 消息身份验证的带密钥哈希”，RFC 2104，DOI 10.17487/RFC2104，1997 年 2 月，<https://www.rfc-editor.org/info/rfc2104>。

[RFC2119]

Bradner, S.，“用于 RFC 中指明要求级别的关键词”，BCP 14， RFC 2119，DOI 10.17487/RFC2119，1997 年 3 月， <https://www.rfc-editor.org/info/rfc2119>。

[RFC3279]

Bassham, L.、Polk, W. 和 R. Housley，“互联网 X.509 公钥基础设施证书和证书撤销列表（CRL）配置文件的算法与标识符”，RFC 3279，DOI 10.17487/RFC3279，2002 年 5 月，<https://www.rfc-editor.org/info/rfc3279>。

[RFC5116]

McGrew, D.，“认证加密的接口和 算法”，RFC 5116，DOI 10.17487/RFC5116，2008 年 1 月，<https://www.rfc-editor.org/info/rfc5116>。

[RFC5280]

Cooper, D.、Santesson, S.、 Farrell, S.、Boeyen, S.、Housley, R. 和 W. Polk，“互联网 X.509 公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008 年 5 月，<https://www.rfc-editor.org/info/rfc5280>。

[RFC5705]

Rescorla, E.，“传输层安全（TLS）的 密钥材料导出器”，RFC 5705，DOI 10.17487/RFC5705，2010 年 3 月，<https://www.rfc-editor.org/info/rfc5705>。

[RFC5756]

Turner, S.、Brown, D.、Yiu, K.、Housley, R. 和 T. Polk，“RSAES-OAEP 和 RSASSA-PSS 算法参数的更新”，RFC 5756，DOI 10.17487/RFC5756，2010 年 1 月，<https://www.rfc-editor.org/info/rfc5756>。

[RFC5869]

Krawczyk, H. 和 P. Eronen， “基于 HMAC 的提取并扩展密钥派生函数 （HKDF）”，RFC 5869，DOI 10.17487/RFC5869，2010 年 5 月， <https://www.rfc-editor.org/info/rfc5869>。

[RFC6066]

Eastlake 3rd, D.，“传输层 安全（TLS）扩展：扩展定义”，RFC 6066，DOI 10.17487/RFC6066，2011 年 1 月，<https://www.rfc-editor.org/info/rfc6066>。

[RFC6655]

McGrew, D. 和 D. Bailey， “传输层安全（TLS）的 AES-CCM 密码套件”， RFC 6655，DOI 10.17487/RFC6655，2012 年 7 月， <https://www.rfc-editor.org/info/rfc6655>。

[RFC6960]

Santesson, S.、Myers, M.、 Ankney, R.、Malpani, A.、Galperin, S. 和 C. Adams， “X.509 互联网公钥基础设施在线证书状态 协议——OCSP”，RFC 6960，DOI 10.17487/RFC6960，2013 年 6 月，<https://www.rfc-editor.org/info/rfc6960>。

[RFC6961]

Pettersen, Y.，“传输层 安全（TLS）多证书状态请求扩展”，RFC 6961，DOI 10.17487/RFC6961，2013 年 6 月， <https://www.rfc-editor.org/info/rfc6961>。

[RFC6962]

Laurie, B.、Langley, A. 和 E. Kasper，“证书 透明度”，RFC 6962，DOI 10.17487/RFC6962，2013 年 6 月，<https://www.rfc-editor.org/info/rfc6962>。

[RFC6979]

Pornin, T.，“数字签名算法（DSA）和 椭圆曲线数字签名算法（ECDSA）的确定性使用”，RFC 6979，DOI 10.17487/RFC6979，2013 年 8 月， <https://www.rfc-editor.org/info/rfc6979>。

[RFC7301]

Friedl, S.、Popov, A.、Langley, A. 和 E. Stephan， “传输层安全（TLS）应用层协议 协商扩展”，RFC 7301，DOI 10.17487/RFC7301，2014 年 7 月，<https://www.rfc-editor.org/info/rfc7301>。

[RFC7507]

Moeller, B. 和 A. Langley， “用于防止协议降级攻击的 TLS 回退信号密码套件值（SCSV）”，RFC 7507，DOI 10.17487/RFC7507，2015 年 4 月，<https://www.rfc-editor.org/info/rfc7507>。

[RFC7627]

Bhargavan, K.，编辑、Delignat-Lavaud, A.、Pironti, A.、Langley, A. 和 M. Ray，“传输 层安全（TLS）会话哈希和扩展主秘密值扩展”，RFC 7627，DOI 10.17487/RFC7627，2015 年 9 月， <https://www.rfc-editor.org/info/rfc7627>。

[RFC7748]

Langley, A.、Hamburg, M. 和 S. Turner，“用于 安全性的椭圆曲线”，RFC 7748，DOI 10.17487/RFC7748，2016 年 1 月， <https://www.rfc-editor.org/info/rfc7748>。

[RFC7919]

Gillmor, D.，“传输层安全（TLS）的 协商式有限域临时 Diffie-Hellman 参数”，RFC 7919，DOI 10.17487/RFC7919，2016 年 8 月， <https://www.rfc-editor.org/info/rfc7919>。

[RFC8017]

Moriarty, K.，编辑、Kaliski, B.、Jonsson, J. 和 A. Rusch，“PKCS #1：RSA 密码学规范 2.2 版”，RFC 8017，DOI 10.17487/RFC8017，2016 年 11 月， <https://www.rfc-editor.org/info/rfc8017>。

[RFC8032]

Josefsson, S. 和 I. Liusvaara，“Edwards 曲线数字签名算法 （EdDSA）”，RFC 8032，DOI 10.17487/RFC8032，2017 年 1 月， <https://www.rfc-editor.org/info/rfc8032>。

[RFC8126]

Cotton, M.、Leiba, B. 和 T. Narten，“在 RFC 中编写 IANA 注意事项章节的指南”，BCP 26， RFC 8126，DOI 10.17487/RFC8126，2017 年 6 月， <https://www.rfc-editor.org/info/rfc8126>。

[RFC8174]

Leiba, B.，“RFC 2119 关键词中 大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017 年 5 月， <https://www.rfc-editor.org/info/rfc8174>。

[RFC8439]

Nir, Y. 和 A. Langley，“用于 IETF 协议的 ChaCha20 和 Poly1305”，RFC 8439，DOI 10.17487/RFC8439，2018 年 6 月， <https://www.rfc-editor.org/info/rfc8439>。

[RFC8701]

Benjamin, D.，“将生成随机扩展并保持可扩展性 （GREASE）应用于 TLS 可扩展性”，RFC 8701，DOI 10.17487/RFC8701，2020 年 1 月， <https://www.rfc-editor.org/info/rfc8701>。

[RFC8996]

Moriarty, K. 和 S. Farrell， “弃用 TLS 1.0 和 TLS 1.1”，BCP 195，RFC 8996，DOI 10.17487/RFC8996，2021 年 3 月，<https://www.rfc-editor.org/info/rfc8996>。

[SHS]

“安全哈希标准”，美国国家 标准与技术研究院，DOI 10.6028/nist.fips.180-4，2015 年， <https://doi.org/10.6028/nist.fips.180-4>。

[X690]

ITU-T，“信息技术——ASN.1 编码规则：基本编码规则（BER）、规范编码规则 （CER）和可辨别编码规则（DER）规范”，ITU-T 建议 X.690，2021 年 2 月，<https://www.itu.int/rec/T-REC-X.690-202102-I/en>。

12.2. 资料性参考文献

[AEAD-LIMITS]

Luykx, A. 和 K. Paterson， “TLS 中认证加密使用的限制”，2017 年 8 月，<https://eprint.iacr.org/2024/051>。

[BBFGKZ16]

Bhargavan, K.、Brzuska, C.、 Fournet, C.、Green, M.、Kohlweiss, M. 和 S. Zanella-Beguelin，“密钥交换协议中的 降级恢复能力”，IEEE，2016 IEEE 安全与隐私研讨会（SP），第 506-525 页，DOI 10.1109/sp.2016.37，2016 年 5 月，<https://doi.org/10.1109/sp.2016.37>。

[BBK17]

Bhargavan, K.、Blanchet, B. 和 N. Kobeissi，“TLS 1.3 标准候选的 已验证模型和参考实现”，IEEE，2017 IEEE 安全 与隐私研讨会（SP），第 483-502 页，DOI 10.1109/sp.2017.26，2017 年 5 月， <https://doi.org/10.1109/sp.2017.26>。

[BDFKPPRSZZ16]

Bhargavan, K.、Delignat-Lavaud, A.、Fournet, C.、Kohlweiss, M.、Pan, J.、Protzenko, J.、Rastogi, A.、 Swamy, N.、Zanella-Beguelin, S. 和 J. Zinzindohoue，“实现并证明 TLS 1.3 记录层”，2017 年 IEEE 安全与隐私研讨会（圣何塞）论文集，2016 年 12 月，<https://eprint.iacr.org/2016/1178>。

[Ben17a]

Benjamin, D.，“在 IETF 100 TLS 工作组上的演示”，IETF 100 会议记录，2017 年 11 月，<https://datatracker.ietf.org/meeting/100/materials/slides-100-tls-sessa-tls13/>。

[Ben17b]

Benjamin, D.，“来自 Chrome 的更多 TLS 1.3 结果”，发送给 TLS 邮件 列表的消息，2017 年 12 月 18 日， <https://mailarchive.ietf.org/arch/msg/tls/i9blmvG2BEPf1s1OJkenHknRw9c/>。

[Blei98]

Bleichenbacher, D.，“针对基于 RSA 加密标准 PKCS #1 的协议的选择密文攻击”，CRYPTO '98 论文集，1998 年，<https://link.springer.com/chapter/10.1007/bfb0055716>。

[BMMRT15]

Badertscher, C.、Matt, C.、 Maurer, U.、Rogaway, P. 和 B. Tackmann，“增强安全 信道与 TLS 1.3 记录层的目标”，ProvSec 2015，2015 年 9 月，<https://eprint.iacr.org/2015/394>。

[BT16]

Bellare, M. 和 B. Tackmann， “认证加密的多用户安全性：TLS 1.3 中的 AES-GCM”，CRYPTO 2016 论文集，2016 年 7 月，<https://eprint.iacr.org/2016/564>。

[CCG16]

Cohn-Gordon, K.、Cremers, C. 和 L. Garratt，“论泄露后 安全性”，IEEE，2016 IEEE 第 29 届计算机安全基础研讨会（CSF），第 164-178 页，DOI 10.1109/csf.2016.19，2016 年 6 月，<https://doi.org/10.1109/csf.2016.19>。

[CHECKOWAY]

Checkoway, S.、Maskiewicz, J.、 Garman, C.、Fried, J.、Cohney, S.、Green, M.、Heninger, N.、Weinmann, R.、 Rescorla, E. 和 H. Shacham， “Juniper Dual EC 事件的系统分析”，ACM，2016 年 ACM SIGSAC 计算机与通信安全会议论文集，第 468-479 页，DOI 10.1145/2976749.2978395，2016 年 10 月，<https://doi.org/10.1145/2976749.2978395>。

[CHHSV17]

Cremers, C.、Horvat, M.、Hoyland, J.、van der Merwe, T. 和 S. Scott，“尴尬的握手： 修订版 18 中握手后模式下客户端/服务器对客户端身份验证的认知可能不一致”， 发送给 TLS 邮件列表的消息， 2017 年 2 月 10 日，<https://mailarchive.ietf.org/arch/msg/tls/crdSCgiW-94z2joulYJtuA52E9E/>。

[CHSV16]

Cremers, C.、Horvat, M.、Scott, S. 和 T. van der Merwe， “TLS 1.3 的自动分析与验证：0-RTT、恢复 和延迟身份验证”，IEEE，2016 IEEE 安全与隐私研讨会（SP），第 470-485 页， DOI 10.1109/sp.2016.35，2016 年 5 月，<https://doi.org/10.1109/sp.2016.35>。

[CK01]

Canetti, R. 和 H. Krawczyk， “密钥交换协议分析及其在构建安全 信道中的使用”，Springer Berlin Heidelberg，计算机科学讲义，第 453-474 页，DOI 10.1007/3-540-44987-6_28，ISBN ["9783540420705", "9783540449874"]，2001 年，<https://doi.org/10.1007/3-540-44987-6_28>。

[CLINIC]

Miller, B.、Huang, L.、Joseph, A. 和 J. Tygar，“我知道你为何去了诊所：HTTPS 流量分析的风险与实现”，Springer International Publishing，计算机科学讲义，第 143-163 页，DOI 10.1007/978-3-319-08506-7_8，ISBN ["9783319085050", "9783319085067"]，2014 年，<https://doi.org/10.1007/978-3-319-08506-7_8>。

[DFGS15]

Dowling, B.、Fischlin, M.、 Guenther, F. 和 D. Stebila， “TLS 1.3 draft-10 完整握手和预共享密钥握手协议的密码学分析”， ACM CCS 2015 论文集，2015 年 10 月，<https://eprint.iacr.org/2015/914>。

[DFGS16]

Dowling, B.、Fischlin, M.、 Guenther, F. 和 D. Stebila， “TLS 1.3 draft-10 完整握手和预共享密钥握手协议的密码学分析”， TRON 2016，2016 年 2 月，<https://eprint.iacr.org/2016/081>。

[DH76]

Diffie, W. 和 M. Hellman， “密码学的新方向”，电气与电子工程师协会（IEEE）， IEEE 信息论汇刊，第 22 卷第 6 期，第 644-654 页，DOI 10.1109/tit.1976.1055638，1976 年 11 月，<https://doi.org/10.1109/tit.1976.1055638>。

[DOW92]

Diffie, W.、Van Oorschot, P. 和 M. Wiener，“身份验证和 认证密钥交换”，Springer Science and Business Media LLC，Designs, Codes and Cryptography，第 2 卷第 2 期，第 107-125 页，DOI 10.1007/bf00124891， 1992 年 6 月，<https://doi.org/10.1007/bf00124891>。

[DSA-1571-1]

Weimer, F.，“[安全] [DSA 1571-1] 新 openssl 软件包修复可预测随机数生成器”，发送给 debian-security-announce 邮件列表的消息，2008 年 5 月，<https://www.debian.org/security/2008/dsa-1571>。

[DSS]

“数字签名标准（DSS）”，美国国家标准与技术研究院，DOI 10.6028/nist.fips.186-5，2023 年 2 月，<https://doi.org/10.6028/nist.fips.186-5>。

[ECDP]

Chen, L.、Moody, D.、Regenscheid, A.、Robinson, A. 和 K. Randall，“基于离散对数的密码学建议： 椭圆曲线域参数”，美国国家标准与技术研究院，DOI 10.6028/nist.sp.800-186，2023 年 2 月，<https://doi.org/10.6028/nist.sp.800-186>。

[FETCH]

WHATWG，“Fetch”，WHATWG 现行标准，<https://fetch.spec.whatwg.org/>。 提交快照： https://fetch.spec.whatwg.org/commit-snapshots/4775fcb48042c8411df497c0b7cf167b4240004f/

[FG17]

Fischlin, M. 和 F. Guenther， “零往返时间重放攻击：TLS 1.3 握手候选方案的案例”，Euro S&P 2017 论文集，2017 年 4 月，<https://eprint.iacr.org/2017/082>。

[FGSW16]

Fischlin, M.、Guenther, F.、 Schmidt, B. 和 B. Warinschi， “密钥交换中的密钥确认：形式化处理及其对 TLS 1.3 的影响”， 2016 年 IEEE 安全与隐私研讨会（奥克兰）论文集，DOI 10.1109/SP.2016.34，2016 年，<http://ieeexplore.ieee.org/document/7546517/>。

[FW15]

Weimer, F.，“利用 TLS 完美前向保密性 分解 RSA 密钥”，Red Hat 博客，2015 年 9 月 2 日，<https://www.redhat.com/en/blog/factoring-rsa-keys-tls-perfect-forward-secrecy>。

[HCJC16]

Husák, M.、Čermák, M.、Jirsík, T. 和 P. Čeleda，“使用被动 SSL/TLS 指纹识别进行 HTTPS 流量分析和客户端识别”， Springer Science and Business Media LLC，EURASIP 信息安全期刊，第 2016 卷， 第 1 期，DOI 10.1186/s13635-016-0030-7，2016 年 2 月，<https://doi.org/10.1186/s13635-016-0030-7>。

[HGFS15]

Hlauschek, C.、Gruber, M.、 Fankhauser, F. 和 C. Schanes，“撬开潘多拉魔盒：针对 TLS 的 KCI 攻击”， USENIX 攻击技术研讨会论文集，2015 年，<https://www.usenix.org/conference/woot15/workshop-program/presentation/hlauschek>。

[JSS15]

Jager, T.、Schwenk, J. 和 J. Somorovsky，“TLS 1.3 和 QUIC 抵御 PKCS#1 v1.5 加密弱点的安全性”，ACM，第 22 届 ACM SIGSAC 计算机与通信安全会议论文集，第 1185-1196 页，DOI 10.1145/2810103.2813657，2015 年 10 月，<https://doi.org/10.1145/2810103.2813657>。

[Kraw10]

Krawczyk, H.，“密码学 提取和密钥派生：HKDF 方案”，CRYPTO 2010 论文集，2010 年，<https://eprint.iacr.org/2010/264>。

[Kraw16]

Krawczyk, H.，“用于密钥交换的单向到双向 身份验证编译器（及其在 TLS 1.3 客户端身份验证中的应用）”，ACM CCS 2016 论文集，2016 年 10 月，<https://eprint.iacr.org/2016/711>。

[KW16]

Krawczyk, H. 和 H. Wee，“OPTLS 协议与 TLS 1.3”，Euro S&P 2016 论文集，2016 年 3 月，<https://eprint.iacr.org/2015/978>。

[LXZFH16]

Li, X.、Xu, J.、Zhang, Z.、Feng, D. 和 H. Hu，“TLS 1.3 候选方案的多次握手安全性”， IEEE，2016 IEEE 安全与隐私研讨会 （SP），第 486-505 页，DOI 10.1109/sp.2016.36，2016 年 5 月，<https://doi.org/10.1109/sp.2016.36>。

[Mac17]

MacCarthaigh, C.，“TLS 1.3 0-RTT 安全审查”，2017 年 5 月， <https://github.com/tlswg/tls13-spec/issues/1001>。

[MM24]

Moustafa, M.、Sethi, M. 和 T. Aura，“TLS 中原始公钥与身份的 错误绑定”，arxiv:2411.09770，2025 年 9 月 29 日，<https://arxiv.org/pdf/2411.09770>。

[PS18]

Patton, C. 和 T. Shrimpton， “部分规定的信道：不省略内容的 TLS 1.3 记录层”，2018 年，<https://eprint.iacr.org/2018/634>。

[PSK-FINISHED]

Cremers, C.、Horvat, M.、van der Merwe, T. 和 S. Scott， “修订版 10：如果在 PSK 期间允许客户端身份验证，可能存在攻击”， 发送给 TLS 邮件列表的消息， 2015 年 10 月 31 日，<https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA/>。

[REKEY]

Abdalla, M. 和 M. Bellare， “延长密钥生存期：重新生成密钥技术安全性的比较分析”，Springer Berlin Heidelberg，计算机科学讲义，第 546-559 页，DOI 10.1007/3-540-44448-3_42，ISBN ["9783540414049", "9783540444480"]，2000 年，<https://doi.org/10.1007/3-540-44448-3_42>。

[Res17a]

Rescorla, E.，“Firefox TLS 1.3 中间盒实验的初步数据”，发送给 TLS 邮件列表的消息，2017 年 12 月 5 日， <https://mailarchive.ietf.org/arch/msg/tls/RBp0X-OWNuWXugFJRV7c_hIU0dI/>。

[Res17b]

Rescorla, E.，“更多兼容性 测量结果”，发送给 TLS 邮件 列表的消息，2017 年 12 月 22 日， <https://mailarchive.ietf.org/arch/msg/tls/6pGGT-wm5vSkacMFPEPvFMEnj-M/>。

[RFC2246]

Dierks, T. 和 C. Allen，“TLS 协议 1.0 版”，RFC 2246，DOI 10.17487/RFC2246，1999 年 1 月，<https://www.rfc-editor.org/info/rfc2246>。

[RFC3552]

Rescorla, E. 和 B. Korver， “编写 RFC 安全注意事项文本的指南”， BCP 72，RFC 3552，DOI 10.17487/RFC3552，2003 年 7 月，<https://www.rfc-editor.org/info/rfc3552>。

[RFC4086]

Eastlake 3rd, D.、Schiller, J. 和 S. Crocker，“安全性的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005 年 6 月，<https://www.rfc-editor.org/info/rfc4086>。

[RFC4346]

Dierks, T. 和 E. Rescorla， “传输层安全（TLS）协议 1.1 版”， RFC 4346，DOI 10.17487/RFC4346，2006 年 4 月， <https://www.rfc-editor.org/info/rfc4346>。

[RFC4366]

Blake-Wilson, S.、Nystrom, M.、 Hopwood, D.、Mikkelsen, J. 和 T. Wright，“传输层 安全（TLS）扩展”，RFC 4366，DOI 10.17487/RFC4366，2006 年 4 月，<https://www.rfc-editor.org/info/rfc4366>。

[RFC4492]

Blake-Wilson, S.、Bolyard, N.、 Gupta, V.、Hawk, C. 和 B. Moeller，“传输层安全（TLS）的椭圆曲线密码学 （ECC）密码套件”，RFC 4492，DOI 10.17487/RFC4492，2006 年 5 月， <https://www.rfc-editor.org/info/rfc4492>。

[RFC5077]

Salowey, J.、Zhou, H.、Eronen, P. 和 H. Tschofenig， “无需服务器端状态的传输层安全（TLS）会话恢复”，RFC 5077，DOI 10.17487/RFC5077，2008 年 1 月，<https://www.rfc-editor.org/info/rfc5077>。

[RFC5246]

Dierks, T. 和 E. Rescorla， “传输层安全（TLS）协议 1.2 版”， RFC 5246，DOI 10.17487/RFC5246，2008 年 8 月， <https://www.rfc-editor.org/info/rfc5246>。

[RFC5763]

Fischl, J.、Tschofenig, H. 和 E. Rescorla，“使用 数据报传输层安全（DTLS）建立安全实时传输协议（SRTP）安全上下文的框架”，RFC 5763，DOI 10.17487/RFC5763，2010 年 5 月，<https://www.rfc-editor.org/info/rfc5763>。

[RFC5764]

McGrew, D. 和 E. Rescorla， “用于为安全实时传输协议（SRTP）建立密钥的 数据报传输层安全（DTLS）扩展”，RFC 5764，DOI 10.17487/RFC5764，2010 年 5 月，<https://www.rfc-editor.org/info/rfc5764>。

[RFC5929]

Altman, J.、Williams, N. 和 L. Zhu，“TLS 的信道绑定”， RFC 5929，DOI 10.17487/RFC5929，2010 年 7 月， <https://www.rfc-editor.org/info/rfc5929>。

[RFC6091]

Mavrogiannopoulos, N. 和 D. Gillmor，“使用 OpenPGP 密钥进行传输层安全 （TLS）身份验证”，RFC 6091，DOI 10.17487/RFC6091，2011 年 2 月，<https://www.rfc-editor.org/info/rfc6091>。

[RFC6101]

Freier, A.、Karlton, P. 和 P. Kocher，“安全套接字层 （SSL）协议 3.0 版”，RFC 6101，DOI 10.17487/RFC6101，2011 年 8 月，<https://www.rfc-editor.org/info/rfc6101>。

[RFC6176]

Turner, S. 和 T. Polk，“禁止安全套接字层（SSL）2.0 版”，RFC 6176，DOI 10.17487/RFC6176，2011 年 3 月， <https://www.rfc-editor.org/info/rfc6176>。

[RFC6520]

Seggelmann, R.、Tuexen, M. 和 M. Williams，“传输层 安全（TLS）和数据报传输层安全（DTLS）心跳扩展”， RFC 6520，DOI 10.17487/RFC6520，2012 年 2 月， <https://www.rfc-editor.org/info/rfc6520>。

[RFC7250]

Wouters, P.，编辑、Tschofenig, H.， 编辑、Gilmore, J.、Weiler, S. 和 T. Kivinen，“在 传输层安全（TLS）和数据报传输层安全（DTLS）中使用原始公钥”，RFC 7250，DOI 10.17487/RFC7250，2014 年 6 月， <https://www.rfc-editor.org/info/rfc7250>。

[RFC7465]

Popov, A.，“禁止 RC4 密码 套件”，RFC 7465，DOI 10.17487/RFC7465，2015 年 2 月， <https://www.rfc-editor.org/info/rfc7465>。

[RFC7568]

Barnes, R.、Thomson, M.、Pironti, A. 和 A. Langley， “弃用安全套接字层 3.0 版”，RFC 7568，DOI 10.17487/RFC7568，2015 年 6 月， <https://www.rfc-editor.org/info/rfc7568>。

[RFC7624]

Barnes, R.、Schneier, B.、 Jennings, C.、Hardie, T.、 Trammell, B.、Huitema, C. 和 D. Borkmann，“面对普遍监控的 机密性：威胁模型和问题陈述”，RFC 7624，DOI 10.17487/RFC7624，2015 年 8 月， <https://www.rfc-editor.org/info/rfc7624>。

[RFC7685]

Langley, A.，“传输层 安全（TLS）ClientHello 填充扩展”，RFC 7685，DOI 10.17487/RFC7685，2015 年 10 月，<https://www.rfc-editor.org/info/rfc7685>。

[RFC7924]

Santesson, S. 和 H. Tschofenig，“传输层安全（TLS）缓存 信息扩展”，RFC 7924，DOI 10.17487/RFC7924，2016 年 7 月，<https://www.rfc-editor.org/info/rfc7924>。

[RFC8305]

Schinazi, D. 和 T. Pauly， “Happy Eyeballs 第 2 版：使用并发获得更好的连接性”，RFC 8305，DOI 10.17487/RFC8305，2017 年 12 月，<https://www.rfc-editor.org/info/rfc8305>。

[RFC8422]

Nir, Y.、Josefsson, S. 和 M. Pegourie-Gonnard，“传输层安全（TLS） 1.2 版及更早版本的椭圆曲线密码学（ECC）密码套件”，RFC 8422，DOI 10.17487/RFC8422，2018 年 8 月， <https://www.rfc-editor.org/info/rfc8422>。

[RFC8446]

Rescorla, E.，“传输层 安全（TLS）协议 1.3 版”，RFC 8446， DOI 10.17487/RFC8446，2018 年 8 月，<https://www.rfc-editor.org/info/rfc8446>。

[RFC8447]

Salowey, J. 和 S. Turner， “TLS 和 DTLS 的 IANA 注册表更新”，RFC 8447，DOI 10.17487/RFC8447，2018 年 8 月， <https://www.rfc-editor.org/info/rfc8447>。

[RFC8448]

Thomson, M.，“TLS 1.3 的握手跟踪 示例”，RFC 8448，DOI 10.17487/RFC8448，2019 年 1 月，<https://www.rfc-editor.org/info/rfc8448>。

[RFC8449]

Thomson, M.，“TLS 的记录大小限制 扩展”，RFC 8449，DOI 10.17487/RFC8449，2018 年 8 月，<https://www.rfc-editor.org/info/rfc8449>。

[RFC8470]

Thomson, M.、Nottingham, M. 和 W. Tarreau，“在 HTTP 中使用早期数据”，RFC 8470，DOI 10.17487/RFC8470，2018 年 9 月，<https://www.rfc-editor.org/info/rfc8470>。

[RFC8773]

Housley, R.，“使用外部预共享密钥进行 基于证书身份验证的 TLS 1.3 扩展”，RFC 8773，DOI 10.17487/RFC8773，2020 年 3 月， <https://www.rfc-editor.org/info/rfc8773>。

[RFC8844]

Thomson, M. 和 E. Rescorla， “使用会话描述协议（SDP）的 TLS 用法中的未知密钥共享攻击”，RFC 8844，DOI 10.17487/RFC8844，2021 年 1 月， <https://www.rfc-editor.org/info/rfc8844>。

[RFC8870]

Jennings, C.、Mattsson, J.、 McGrew, D.、Wing, D. 和 F. Andreasen，“用于 DTLS 和安全 RTP 的加密密钥传输”，RFC 8870，DOI 10.17487/RFC8870，2021 年 1 月，<https://www.rfc-editor.org/info/rfc8870>。

[RFC8879]

Ghedini, A. 和 V. Vasiliev， “TLS 证书压缩”，RFC 8879，DOI 10.17487/RFC8879，2020 年 12 月，<https://www.rfc-editor.org/info/rfc8879>。

[RFC8937]

Cremers, C.、Garratt, L.、 Smyshlyaev, S.、Sullivan, N. 和 C. Wood，“安全协议的随机性改进”， RFC 8937，DOI 10.17487/RFC8937，2020 年 10 月， <https://www.rfc-editor.org/info/rfc8937>。

[RFC9001]

Thomson, M.，编辑 和 S. Turner， 编辑，“使用 TLS 保护 QUIC”，RFC 9001，DOI 10.17487/RFC9001，2021 年 5 月， <https://www.rfc-editor.org/info/rfc9001>。

[RFC9112]

Fielding, R.，编辑、Nottingham, M.， 编辑 和 J. Reschke，编辑，“HTTP/1.1”，STD 99，RFC 9112，DOI 10.17487/RFC9112，2022 年 6 月， <https://www.rfc-editor.org/info/rfc9112>。

[RFC9147]

Rescorla, E.、Tschofenig, H. 和 N. Modadugu，“数据报 传输层安全（DTLS）协议 1.3 版”，RFC 9147，DOI 10.17487/RFC9147，2022 年 4 月， <https://www.rfc-editor.org/info/rfc9147>。

[RFC9149]

Pauly, T.、Schinazi, D. 和 C.A. Wood，“TLS 票据 请求”，RFC 9149，DOI 10.17487/RFC9149，2022 年 4 月， <https://www.rfc-editor.org/info/rfc9149>。

[RFC9162]

Laurie, B.、Messeri, E. 和 R. Stradling，“证书 透明度 2.0 版”，RFC 9162，DOI 10.17487/RFC9162，2021 年 12 月，<https://www.rfc-editor.org/info/rfc9162>。

[RFC9257]

Housley, R.、Hoyland, J.、 Sethi, M. 和 C. A. Wood， “TLS 中外部预共享密钥（PSK）使用指南”， RFC 9257，DOI 10.17487/RFC9257，2022 年 7 月， <https://www.rfc-editor.org/info/rfc9257>。

[RFC9258]

Benjamin, D. 和 C. A. Wood， “为 TLS 1.3 导入外部预共享密钥（PSK）”，RFC 9258，DOI 10.17487/RFC9258，2022 年 7 月， <https://www.rfc-editor.org/info/rfc9258>。

[RFC9261]

Sullivan, N.，“TLS 中的导出式身份验证器”， RFC 9261，DOI 10.17487/RFC9261，2022 年 7 月， <https://www.rfc-editor.org/info/rfc9261>。

[RFC9345]

Barnes, R.、Iyengar, S.、Sullivan, N. 和 E. Rescorla， “TLS 和 DTLS 的委托凭据”，RFC 9345，DOI 10.17487/RFC9345，2023 年 7 月， <https://www.rfc-editor.org/info/rfc9345>。

[RFC9525]

Saint-Andre, P. 和 R. Salz， “TLS 中的服务身份”，RFC 9525，DOI 10.17487/RFC9525，2023 年 11 月，<https://www.rfc-editor.org/info/rfc9525>。

[RFC9847]

Salowey, J. 和 S. Turner， “TLS 和 DTLS 的 IANA 注册表更新”，RFC 9847，DOI 10.17487/RFC9847，2025 年 12 月， <https://www.rfc-editor.org/info/rfc9847>。

[RFC9849]

Rescorla, E.、Oku, K.、Sullivan, N. 和 C. A. Wood， “TLS 加密客户端问候”，RFC 9849，DOI 10.17487/RFC9849，2026 年 3 月，<https://www.rfc-editor.org/info/rfc9849>。

[RFC9963]

Benjamin, D. 和 A. Popov， “TLS 1.3 的旧式 RSASSA-PKCS1-v1_5 码位”，RFC 9963，DOI 10.17487/RFC9963，2026 年 4 月， <https://www.rfc-editor.org/info/rfc9963>。

[RSA]

Rivest, R.、Shamir, A. 和 L. Adleman，“一种获得 数字签名和公钥密码系统的方法”，计算机协会（ACM），Communications of the ACM，第 21 卷第 2 期，第 120-126 页，DOI 10.1145/359340.359342，1978 年 2 月，<https://doi.org/10.1145/359340.359342>。

[Selfie]

Drucker, N. 和 S. Gueron， “Selfie：对使用 PSK 的 TLS 1.3 的反思”，2019 年，<https://eprint.iacr.org/2019/347>。

[SIGMA]

Krawczyk, H.，“SIGMA：认证 Diffie-Hellman 的‘签名并计算 MAC’方法及其在 IKE 协议中的使用”，Springer Berlin Heidelberg，计算机科学讲义，第 400-425 页，DOI 10.1007/978-3-540-45146-4_24，ISBN ["9783540406747", "9783540451464"]，2003 年，<https://doi.org/10.1007/978-3-540-45146-4_24>。

[SLOTH]

Bhargavan, K. 和 G. Leurent， “消息记录冲突攻击：攻破 TLS、IKE 和 SSH 中的身份验证”， 互联网协会，2016 年网络与分布式系统安全研讨会论文集，DOI 10.14722/ndss.2016.23418，2016 年，<https://doi.org/10.14722/ndss.2016.23418>。

[SSL2]

Hickman, K. E.，“SSL 协议”，1995 年 2 月 9 日， <https://datatracker.ietf.org/doc/html/draft-hickman-netscape-ssl-00>。

[TIMING]

Boneh, D. 和 D. Brumley， “远程时序攻击在实践中可行”，第 12 届 USENIX 安全研讨会（USENIX Security 03），2003 年，<https://www.usenix.org/conference/12th-usenix-security-symposium/remote-timing-attacks-are-practical>。

[X501]

ITU-T，“信息技术——开放 系统互连——目录：模型”，ITU-T 建议 X.501，ISO/IEC 9594-2:2020，2019 年 10 月，<https://www.itu.int/rec/T-REC-X.501-201910-I/en>。

A.1. 客户端

                           START <----+
          发送 ClientHello |        | 接收 HelloRetryRequest
       [K_send = 早期数据] |        |
                             v        |
        +->               WAIT_SH ----+
        |                    | 接收 ServerHello
        |                    | K_recv = 握手
   可以 |                    V
   发送 |                 WAIT_EE
   早期 |                    | 接收 EncryptedExtensions
   数据 |          +---------+-------+
        |    使用 |                 | 使用证书
        |     PSK |                 v
        |          |            WAIT_CERT_CR
        |          |        接收 |       | 接收 CertificateRequest
        |          | Certificate |       v
        |          |             |    WAIT_CERT
        |          |             |       | 接收 Certificate
        |          |             v       v
        |          |              WAIT_CV
        |          |                   | 接收 CertificateVerify
        |          +-> WAIT_FINISHED <-+
        |                  | 接收 Finished
        +->                | [发送 EndOfEarlyData]
                           | K_send = 握手
                           | [发送 Certificate [+ CertificateVerify]]
 从此处后               | 发送 Finished
 可发送应用数据 -->      | K_send = K_recv = 应用
                           v
                       CONNECTED

请注意，按照上图所示的转换，客户端可能会以明文 或使用早期数据密钥发送由 ServerHello 之后的消息引起的警报。 如果客户端需要发送此类警报，则在可能的情况下应 先将密钥更新为握手密钥。¶

A.2. 服务器

                             START <-----+
            接收 ClientHello |         | 发送 HelloRetryRequest
                               v         |
                            RECVD_CH ----+
                               | 选择参数
                               v
                            NEGOTIATED
                               | 发送 ServerHello
                               | K_send = 握手
                               | 发送 EncryptedExtensions
                               | [发送 CertificateRequest]
可发送                        | [发送 Certificate + CertificateVerify]
应用数据                      | 发送 Finished
从此处 -->                   | K_send = 应用
                      +--------+--------+
              无 0-RTT |                 | 0-RTT
                      |                 |
  K_recv = 握手       |                 | K_recv = 早期数据
[跳过解密错误]        |    +------> WAIT_EOED --+
                      |    |       接收 |       | 接收 EndOfEarlyData
                      |    | 早期数据   |       | K_recv = 握手
                      |    +------------+       |
                      |                         |
                      +-> WAIT_FLIGHT2 <--------+
                               |
                      +--------+--------+
             无身份验证 |                 | 基于证书的客户端身份验证
                      |                 |
                      |                 v
                      |             WAIT_CERT
                      |        接收 |       | 接收 Certificate
                      |       空的  |       v
                      | Certificate |    WAIT_CV
                      |             |       | 接收
                      |             v       | CertificateVerify
                      +-> WAIT_FINISHED <---+
                               | 接收 Finished
                               | K_recv = 应用
                               v
                           CONNECTED

B.1. 记录层

   enum {
       invalid(0),
       change_cipher_spec(20),
       alert(21),
       handshake(22),
       application_data(23),
       (255)
   } ContentType;

   struct {
       ContentType type;
       ProtocolVersion legacy_record_version;
       uint16 length;
       opaque fragment[TLSPlaintext.length];
   } TLSPlaintext;

   struct {
       opaque content[TLSPlaintext.length];
       ContentType type;
       uint8 zeros[length_of_padding];
   } TLSInnerPlaintext;

   struct {
       ContentType opaque_type = application_data; /* 23 */
       ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
       uint16 length;
       opaque encrypted_record[TLSCiphertext.length];
   } TLSCiphertext;

B.2. 警报消息

   enum { warning(1), fatal(2), (255) } AlertLevel;

   enum {
       close_notify(0),
       unexpected_message(10),
       bad_record_mac(20),
       decryption_failed_RESERVED(21),
       record_overflow(22),
       decompression_failure_RESERVED(30),
       handshake_failure(40),
       no_certificate_RESERVED(41),
       bad_certificate(42),
       unsupported_certificate(43),
       certificate_revoked(44),
       certificate_expired(45),
       certificate_unknown(46),
       illegal_parameter(47),
       unknown_ca(48),
       access_denied(49),
       decode_error(50),
       decrypt_error(51),
       export_restriction_RESERVED(60),
       protocol_version(70),
       insufficient_security(71),
       internal_error(80),
       inappropriate_fallback(86),
       user_canceled(90),
       no_renegotiation_RESERVED(100),
       missing_extension(109),
       unsupported_extension(110),
       certificate_unobtainable_RESERVED(111),
       unrecognized_name(112),
       bad_certificate_status_response(113),
       bad_certificate_hash_value_RESERVED(114),
       unknown_psk_identity(115),
       certificate_required(116),
       general_error(117),
       no_application_protocol(120),
       (255)
   } AlertDescription;

   struct {
       AlertLevel level;
       AlertDescription description;
   } Alert;

B.3. 握手协议

   enum {
       hello_request_RESERVED(0),
       client_hello(1),
       server_hello(2),
       hello_verify_request_RESERVED(3),
       new_session_ticket(4),
       end_of_early_data(5),
       hello_retry_request_RESERVED(6),
       encrypted_extensions(8),
       certificate(11),
       server_key_exchange_RESERVED(12),
       certificate_request(13),
       server_hello_done_RESERVED(14),
       certificate_verify(15),
       client_key_exchange_RESERVED(16),
       finished(20),
       certificate_url_RESERVED(21),
       certificate_status_RESERVED(22),
       supplemental_data_RESERVED(23),
       key_update(24),
       message_hash(254),
       (255)
   } HandshakeType;

   struct {
       HandshakeType msg_type;    /* 握手类型 */
       uint24 length;             /* 消息中的剩余字节 */
       select (Handshake.msg_type) {
           case client_hello:          ClientHello;
           case server_hello:          ServerHello;
           case end_of_early_data:     EndOfEarlyData;
           case encrypted_extensions:  EncryptedExtensions;
           case certificate_request:   CertificateRequest;
           case certificate:           Certificate;
           case certificate_verify:    CertificateVerify;
           case finished:              Finished;
           case new_session_ticket:    NewSessionTicket;
           case key_update:            KeyUpdate;
       };
   } Handshake;

   uint16 ProtocolVersion;
   opaque Random[32];

   uint8 CipherSuite[2];    /* 密码套件选择器 */

   struct {
       ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
       Random random;
       opaque legacy_session_id<0..32>;
       CipherSuite cipher_suites<2..2^16-2>;
       opaque legacy_compression_methods<1..2^8-1>;
       Extension extensions<7..2^16-1>;
   } ClientHello;

   struct {
       ProtocolVersion legacy_version = 0x0303;    /* TLS v1.2 */
       Random random;
       opaque legacy_session_id_echo<0..32>;
       CipherSuite cipher_suite;
       uint8 legacy_compression_method = 0;
       Extension extensions<6..2^16-1>;
   } ServerHello;

   struct {
       ExtensionType extension_type;
       opaque extension_data<0..2^16-1>;
   } Extension;

   enum {
       server_name(0),                             /* RFC 6066, 9261 */
       status_request(5),                          /* RFC 6066, 9846 */
       supported_groups(10),                       /* RFC 7919, 9846 */
       signature_algorithms(13),                   /* RFC 9846 */
       use_srtp(14),                               /* RFC 5764 */
       heartbeat(15),                              /* RFC 6520 */
       application_layer_protocol_negotiation(16), /* RFC 7301 */
       client_certificate_type(19),                /* RFC 7250 */
       server_certificate_type(20),                /* RFC 7250 */
       padding(21),                                /* RFC 7685 */
       compress_certificate(27),                   /* RFC 8879 */
       record_size_limit(28),                      /* RFC 8449 */
       delegated_credential(34),                   /* RFC 9345 */
       supported_ekt_ciphers(39),                  /* RFC 8870 */
       pre_shared_key(41),                         /* RFC 9846 */
       early_data(42),                             /* RFC 9846 */
       supported_versions(43),                     /* RFC 9846 */
       cookie(44),                                 /* RFC 9846 */
       psk_key_exchange_modes(45),                 /* RFC 9846 */
       certificate_authorities(47),                /* RFC 9846 */
       oid_filters(48),                            /* RFC 9846 */
       post_handshake_auth(49),                    /* RFC 9846 */
       signature_algorithms_cert(50),              /* RFC 9846 */
       key_share(51),                              /* RFC 9846 */
       transparency_info(52),                      /* RFC 9162 */
       external_id_hash(55),                       /* RFC 8844 */
       external_session_id(56),                    /* RFC 8844 */
       quic_transport_parameters(57),              /* RFC 9001 */
       ticket_request(58),                         /* RFC 9149 */
       ech_outer_extensions(64768),                /* RFC 9849 */
       encrypted_client_hello(65037),              /* RFC 9849 */
       (65535)
   } ExtensionType;

   struct {
       NamedGroup group;
       opaque key_exchange<1..2^16-1>;
   } KeyShareEntry;

   struct {
       KeyShareEntry client_shares<0..2^16-1>;
   } KeyShareClientHello;

   struct {
       NamedGroup selected_group;
   } KeyShareHelloRetryRequest;

   struct {
       KeyShareEntry server_share;
   } KeyShareServerHello;

   struct {
       uint8 legacy_form = 4;
       opaque X[coordinate_length];
       opaque Y[coordinate_length];
   } UncompressedPointRepresentation;

   enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode;

   struct {
       PskKeyExchangeMode ke_modes<1..255>;
   } PskKeyExchangeModes;

   struct {} Empty;

   struct {
       select (Handshake.msg_type) {
           case new_session_ticket:   uint32 max_early_data_size;
           case client_hello:         Empty;
           case encrypted_extensions: Empty;
       };
   } EarlyDataIndication;

   struct {
       opaque identity<1..2^16-1>;
       uint32 obfuscated_ticket_age;
   } PskIdentity;

   opaque PskBinderEntry<32..255>;

   struct {
       PskIdentity identities<7..2^16-1>;
       PskBinderEntry binders<33..2^16-1>;
   } OfferedPsks;

   struct {
       select (Handshake.msg_type) {
           case client_hello: OfferedPsks;
           case server_hello: uint16 selected_identity;
       };
   } PreSharedKeyExtension;

   struct {
       select (Handshake.msg_type) {
           case client_hello:
                ProtocolVersion versions<2..254>;

           case server_hello: /* 以及 HelloRetryRequest */
                ProtocolVersion selected_version;
       };
   } SupportedVersions;

   struct {
       opaque cookie<1..2^16-1>;
   } Cookie;

   enum {
       /* RSASSA-PKCS1-v1_5 算法 */
       rsa_pkcs1_sha256(0x0401),
       rsa_pkcs1_sha384(0x0501),
       rsa_pkcs1_sha512(0x0601),

       /* ECDSA 算法 */
       ecdsa_secp256r1_sha256(0x0403),
       ecdsa_secp384r1_sha384(0x0503),
       ecdsa_secp521r1_sha512(0x0603),

       /* 公钥 OID 为 rsaEncryption 的 RSASSA-PSS 算法 */
       rsa_pss_rsae_sha256(0x0804),
       rsa_pss_rsae_sha384(0x0805),
       rsa_pss_rsae_sha512(0x0806),

       /* EdDSA 算法 */
       ed25519(0x0807),
       ed448(0x0808),

       /* 公钥 OID 为 RSASSA-PSS 的 RSASSA-PSS 算法 */
       rsa_pss_pss_sha256(0x0809),
       rsa_pss_pss_sha384(0x080a),
       rsa_pss_pss_sha512(0x080b),

       /* 旧式算法 */
       rsa_pkcs1_sha1(0x0201),
       ecdsa_sha1(0x0203),

       /* 预留码位 */
       obsolete_RESERVED(0x0000..0x0200),
       dsa_sha1_RESERVED(0x0202),
       obsolete_RESERVED(0x0204..0x0400),
       dsa_sha256_RESERVED(0x0402),
       obsolete_RESERVED(0x0404..0x0500),
       dsa_sha384_RESERVED(0x0502),
       obsolete_RESERVED(0x0504..0x0600),
       dsa_sha512_RESERVED(0x0602),
       obsolete_RESERVED(0x0604..0x06FF),
       private_use(0xFE00..0xFFFF),
       (0xFFFF)
   } SignatureScheme;

   struct {
       SignatureScheme supported_signature_algorithms<2..2^16-2>;
   } SignatureSchemeList;

   enum {
       unallocated_RESERVED(0x0000),

       /* 椭圆曲线组（ECDHE） */
       obsolete_RESERVED(0x0001..0x0016),
       secp256r1(0x0017), secp384r1(0x0018), secp521r1(0x0019),
       obsolete_RESERVED(0x001A..0x001C),
       x25519(0x001D), x448(0x001E),

       /* 有限域组（DHE） */
       ffdhe2048(0x0100), ffdhe3072(0x0101), ffdhe4096(0x0102),
       ffdhe6144(0x0103), ffdhe8192(0x0104),

       /* 预留码位 */
       ffdhe_private_use(0x01FC..0x01FF),
       ecdhe_private_use(0xFE00..0xFEFF),
       obsolete_RESERVED(0xFF01..0xFF02),
       (0xFFFF)
   } NamedGroup;

   struct {
       NamedGroup named_group_list<2..2^16-1>;
   } NamedGroupList;

   opaque DistinguishedName<1..2^16-1>;

   struct {
       DistinguishedName authorities<3..2^16-1>;
   } CertificateAuthoritiesExtension;

   struct {
       opaque certificate_extension_oid<1..2^8-1>;
       opaque certificate_extension_values<0..2^16-1>;
   } OIDFilter;

   struct {
       OIDFilter filters<0..2^16-1>;
   } OIDFilterExtension;

   struct {} PostHandshakeAuth;

   struct {
       Extension extensions<0..2^16-1>;
   } EncryptedExtensions;

   struct {
       opaque certificate_request_context<0..2^8-1>;
       Extension extensions<0..2^16-1>;
   } CertificateRequest;

   enum {
       X509(0),
       OpenPGP_RESERVED(1),
       RawPublicKey(2),
       (255)
   } CertificateType;

   struct {
       select (certificate_type) {
           case RawPublicKey:
             /* 来自 RFC 7250 的 ASN.1_subjectPublicKeyInfo */
             opaque ASN1_subjectPublicKeyInfo<1..2^24-1>;

           case X509:
             opaque cert_data<1..2^24-1>;
       };
       Extension extensions<0..2^16-1>;
   } CertificateEntry;

   struct {
       opaque certificate_request_context<0..2^8-1>;
       CertificateEntry certificate_list<0..2^24-1>;
   } Certificate;

   struct {
       SignatureScheme algorithm;
       opaque signature<0..2^16-1>;
   } CertificateVerify;

   struct {
       opaque verify_data[Hash.length];
   } Finished;

   struct {
       uint32 ticket_lifetime;
       uint32 ticket_age_add;
       opaque ticket_nonce<0..255>;
       opaque ticket<1..2^16-1>;
       Extension extensions<0..2^16-1>;
   } NewSessionTicket;

   struct {} EndOfEarlyData;

   enum {
       update_not_requested(0), update_requested(1), (255)
   } KeyUpdateRequest;

   struct {
       KeyUpdateRequest request_update;
   } KeyUpdate;

B.4. 密码套件

密码套件定义与 HKDF 一起使用的 AEAD 算法和哈希 算法组合。 密码套件名称遵循以下命名约定：¶

   CipherSuite TLS_AEAD_HASH = VALUE;

本规范定义以下与 TLS 1.3 一起使用的密码套件。¶

对应的 AEAD 算法 AEAD_AES_128_GCM、AEAD_AES_256_GCM 和 AEAD_AES_128_CCM 定义于 [RFC5116]。 AEAD_CHACHA20_POLY1305 定义于 [RFC8439]。AEAD_AES_128_CCM_8 定义于 [RFC6655]。对应的 哈希算法定义于 [SHS]。¶

尽管 TLS 1.3 与早期 TLS 版本使用相同的密码套件空间， 但 TLS 1.3 密码套件的定义方式不同，仅规定 对称密码，因此不能用于 TLS 1.2。同样， TLS 1.2 及更低版本的密码套件不能用于 TLS 1.3。¶

新的密码套件值由 IANA 按照 第 11 节所述方式分配。¶

C.1. 随机数 生成和播种

TLS 需要密码学安全的伪随机数生成器 （CSPRNG）。 大多数操作系统都提供性能良好且安全性适当的 CSPRNG， 也可以从密码学库中获取。 建议优先使用现有 CSPRNG 实现，而不是自行创建新实现。 目前已有许多足够安全的密码学库， 且使用许可条件友好。如果这些库仍不能满足要求， [RFC4086] 提供了随机值生成指南。¶

TLS 在以下方面使用随机值：（1）ClientHello 和 ServerHello 中 公开 Random 值等公共协议字段；（2）生成 密钥材料。对于正常工作的 CSPRNG， 这不会构成安全问题，因为无法根据其输出确定 CSPRNG 状态。但是，对于存在缺陷的 CSPRNG， 攻击者可能利用公开输出来确定 CSPRNG 内部状态，从而预测密钥材料， 如 [CHECKOWAY] 和 [DSA-1571-1] 中所述。¶

实现可以通过使用不同的 CSPRNG 分别生成公共值和 私有值，为抵御 此类攻击提供额外安全性。¶

[RFC8937] 描述了 安全协议实现使用长期私钥和确定性签名函数 增强其（伪）随机数生成器的方法。 这可以改善存在缺陷或以其他方式遭到破坏的 随机数生成器所产生的随机性。¶

C.2. 证书与 身份验证

实现负责验证证书的完整性， 并且通常应支持证书撤销消息；参见第 4.5.1.1 节。如果应用配置文件没有给出具体 指示，则应始终验证证书，以确保其由受信任的证书颁发机构 （CA）正确签名。选择和添加信任锚时应非常谨慎。 用户应能够查看有关证书和信任锚的信息。 应用还应强制执行最小和最大密钥大小。例如， 包含弱于 2048 位 RSA 或 224 位 ECDSA 的密钥或签名的认证路径，不适合用于安全应用。¶

请注意，在某些协议中，客户端和服务器模式使用相同 证书是一种常见做法。对此场景尚未进行 广泛分析，高层协议有责任确保 在这种情况下高层语义不存在歧义。¶

C.3. 实现 陷阱

实现经验表明，早期 TLS 规范的某些部分 不易理解，并已成为互操作性和安全问题的来源。 本文档已澄清其中许多领域，但本附录仍简要列出 实现者需要特别注意的最重要事项。¶

TLS 协议问题：¶

• 是否正确处理被分割到 多条 TLS 记录中的握手消息（参见第 5.1 节）？是否正确处理 ClientHello 被分割为多个小片段等边界情况？ 是否会分割超过最大片段大小的握手消息？ 尤其是，Certificate 和 CertificateRequest 握手消息可能大到需要分割。 可以使用 [RFC8879] 中定义的证书压缩 降低发生分割的风险。¶

• 是否在所有未加密 TLS 记录中忽略 TLS 记录层版本号（参见附录 E）？¶

• 是否已确保在所有支持 TLS 1.3 或更高版本的 可能配置中，完全移除对 SSL、RC4、EXPORT 密码 和 MD5（通过“signature_algorithms”扩展）的所有支持， 并且尝试使用这些废弃功能时会正确失败 （参见附录 E）？¶

• 是否正确处理 ClientHello 中的 TLS 扩展， 包括未知扩展？¶

• 服务器请求客户端证书但没有 合适证书可用时，是否正确发送空的 Certificate 消息，而不是省略整个消息（参见 第 4.5.1 节）？¶

• 处理 AEAD-Decrypt 产生的明文片段， 并从末尾扫描 ContentType 时， 如果对等方发送了全部为零的畸形明文， 是否能避免扫描越过明文开头？¶

• 是否正确忽略 ClientHello 中无法识别的密码套件 （第 4.2.2 节）、问候扩展 （第 4.3 节）、命名组 （第 4.3.7 节）、密钥共享值 （第 4.3.8 节）、 支持的版本（第 4.3.1 节） 和签名算法（第 4.3.3 节）？¶

• 作为服务器，对于支持兼容的非对称密钥交换组， 但未在“key_share”扩展中预先提供该组的客户端， 是否会发送 HelloRetryRequest？作为客户端，是否能正确处理 服务器发来的 HelloRetryRequest？¶

密码学细节：¶

• 使用哪些对策防止时序攻击 [TIMING]？¶

• 使用 Diffie-Hellman 密钥交换时，是否正确保留 协商密钥中的前导零字节（参见第 7.4.1 节）？¶

• TLS 客户端是否检查服务器发送的 Diffie-Hellman 参数是否可接受（参见第 4.3.8.1 节）？¶

• 生成 Diffie-Hellman 私有值、ECDSA“k”参数 和其他安全关键值时，是否使用强健且最重要的是正确播种的随机数 生成器（参见附录 C.1）？ 建议实现按照 [RFC6979] 的规定实现“确定性 ECDSA”。 请注意，确定性 ECDSA 和 EdDSA 等纯确定性椭圆曲线密码学 （ECC）签名，在易于物理接触的物联网（IoT）设备中， 可能容易受到某些侧信道攻击和故障注入攻击。¶

• 是否将 Diffie-Hellman 公钥值和共享秘密值 用零填充至组大小（参见第 4.3.8.1 节和第 7.4.1 节）？¶

• 生成签名后是否验证签名，以防止 RSA-CRT 密钥泄露 [FW15]？¶

C.4. 客户端和服务器 跟踪防范

客户端不应在多个连接中复用同一票据。 复用票据会使被动观察者能够关联不同连接。 签发票据的服务器应至少提供与客户端可能使用的 连接数相同数量的票据；例如，使用 HTTP/1.1 [RFC9112] 的 Web 浏览器可能会向 服务器打开六个连接。服务器应 在每个连接上签发新票据。这可确保客户端在创建新连接时 始终能够使用新票据。¶

向服务器提供票据还会使服务器能够关联 不同连接。这与是否复用票据无关。 客户端应用不应跨本应互不关联的连接提供票据。 例如，[FETCH] 定义了网络分区键， 用于分隔 Web 浏览器中的缓存查找。¶

建议选择外部身份标签时， 不要使其提供有关用户身份的额外信息。 例如，如果标签包含电子邮件地址， 则被动攻击者可以轻易据此识别用户， 而客户端的 Certificate 是加密的。可通过多种方式 避免这种风险，包括：（1）使用随机身份标签； （2）使用服务器已知的密钥预先加密身份；或（3） 使用加密客户端问候 [RFC9849]。¶

如果外部 PSK 身份用于多个连接， 外部观察者通常能够跨连接跟踪 客户端和/或服务器。 使用加密客户端问候 [RFC9849] 可以缓解此风险；轮换或加密 PSK 身份的 TLS 外部机制 也可以缓解此风险。¶

C.5. 未经身份验证的 操作

早期 TLS 版本提供了基于匿名 Diffie-Hellman、 明确不进行身份验证的密码套件。这些模式已在 TLS 1.3 中弃用。 不过，仍可通过多种方法协商不提供 可验证服务器身份验证的参数，包括：¶

• 原始公钥 [RFC7250]。¶

• 使用证书中包含的公钥，但不 验证证书链或其任何内容。¶

单独使用任一技术都容易受到中间人攻击， 因而不适合一般用途。不过，也可以通过 带外验证服务器公钥、首次使用时信任， 或信道绑定等机制，将此类连接与外部身份验证机制 绑定（不过 [RFC5929] 中描述的信道绑定并未针对 TLS 1.3 定义）。如果未使用此类机制， 则连接无法抵御主动中间人攻击；在缺少明确配置 或具体应用配置文件的情况下，应用不得以这种方式使用 TLS。¶

E.1. 与旧版服务器 协商

希望与不支持 TLS 1.3 的服务器协商的 TLS 1.3 客户端， 会发送普通的 TLS 1.3 ClientHello，其中 ClientHello.legacy_version 为 0x0303（TLS 1.2）， 但“supported_versions”扩展中包含正确的版本。 如果服务器不支持 TLS 1.3，则会以包含较旧版本号的 ServerHello 响应。 如果客户端同意使用此版本，则协商将按照该协议版本的相应流程继续。 使用票据进行恢复的客户端应使用先前协商的版本发起连接。¶

请注意，0-RTT 数据与旧版服务器不兼容，并且在不知道 服务器支持 TLS 1.3 的情况下不应发送。 参见附录 E.3。¶

如果服务器选择的版本不受客户端支持（或不可接受）， 客户端必须使用“protocol_version”警报中止握手。¶

已知某些旧式服务器实现未正确实现 TLS 规范，并且在遇到其不了解的 TLS 扩展或版本时可能中止连接。 与有缺陷服务器的互操作性是一个复杂主题，超出了本文档的范围。 可能需要进行多次连接尝试才能协商出 向后兼容的连接；不过，这种做法容易受到 降级攻击，因此不建议使用。¶

E.2. 与旧版客户端 协商

TLS 服务器也可能收到指明的版本号低于其最高支持版本的 ClientHello。如果存在“supported_versions”扩展， 服务器必须按照第 4.3.1 节所述，使用该扩展进行协商。 如果不存在“supported_versions”扩展， 服务器必须在 ClientHello.legacy_version 与 TLS 1.2 中选择较低者。例如，如果服务器支持 TLS 1.0、1.1 和 1.2， 而 legacy_version 为 TLS 1.0，则服务器将使用 TLS 1.0 ServerHello 继续。 如果不存在“supported_versions”扩展，并且服务器仅支持 高于 ClientHello.legacy_version 的版本，则服务器必须 使用“protocol_version”警报中止握手。¶

请注意，早期 TLS 版本并未在所有情况下明确规定记录层 版本号的值（TLSPlaintext.legacy_record_version）。服务器 会在此字段中收到各种 TLS 1.x 版本，但其值 必须始终被忽略。¶

E.3. 0-RTT 向后 兼容性

0-RTT 数据与旧版服务器不兼容。旧版服务器会用较旧的 ServerHello 响应 ClientHello，但无法正确跳过 0-RTT 数据，并且无法完成握手。当客户端尝试使用 0-RTT 时， 这可能会造成问题，尤其是在多服务器部署中。例如， 某个部署可能逐步部署 TLS 1.3，其中部分服务器 实现 TLS 1.3，部分服务器实现 TLS 1.2；或者某个 TLS 1.3 部署 可能被降级到 TLS 1.2。¶

尝试发送 0-RTT 数据的客户端在收到 TLS 1.2 或更早版本的 ServerHello 时必须使连接失败。 随后可以禁用 0-RTT 并重试连接。 为避免降级攻击，客户端不应禁用 TLS 1.3，而只应禁用 0-RTT。¶

为避免此错误条件，多服务器部署在启用 0-RTT 之前， 应确保已统一且稳定地部署不使用 0-RTT 的 TLS 1.3。¶

E.4. 中间盒 兼容模式

现场测量 [Ben17a] [Ben17b] [Res17a] [Res17b] 发现，当 TLS 客户端/服务器双方协商 TLS 1.3 时， 大量中间盒会出现错误行为。实现可以通过让 TLS 1.3 握手 看起来更像 TLS 1.2 握手，提高通过这些中间盒 建立连接的成功率：¶

• 客户端始终在 ClientHello 中提供非空会话 ID， 如第 4.2.2 节的 legacy_session_id 部分所述。¶

• 如果不提供早期数据，客户端会在其第二个消息批次之前 立即发送一条虚假的 change_cipher_spec 记录 （参见第 5 节的第三段）。 该记录可以位于第二个 ClientHello 之前，也可以位于加密的 握手消息批次之前。如果提供早期数据，则此记录 紧跟在第一个 ClientHello 之后。¶

• 服务器在其第一条握手消息之后立即发送一条虚假的 change_cipher_spec 记录。该记录可以位于 ServerHello 或 HelloRetryRequest 之后。¶

综合使用这些变更后，TLS 1.3 握手会类似于 TLS 1.2 会话恢复，从而提高通过中间盒成功建立连接的概率。 此“兼容模式”部分经过协商：客户端可以选择是否提供会话 ID， 而服务器必须回显该值。任一方都可以在握手期间的任何时间发送 change_cipher_spec，因为对等方必须忽略该记录； 但如果客户端发送非空会话 ID，服务器必须按照本附录所述 发送 change_cipher_spec。¶

E.5. 与向后兼容性相关的 安全限制

协商使用旧版 TLS 的实现，在可用时应优先使用 具有前向保密性的 AEAD 密码套件。¶

出于 [RFC7465] 中所述原因，RC4 密码套件的安全性被认为不足。无论出于何种原因， 实现不得为任何 TLS 版本提供或协商 RC4 密码套件。¶

旧版 TLS 允许使用强度非常低的密码。 无论出于何种原因，强度低于 112 位的密码不得为任何 TLS 版本提供或协商。¶

出于 [RFC6176]、 [RFC7568] 和 [RFC8996] 中列出的原因，SSL 2.0 [SSL2]、SSL 3.0 [RFC6101]、TLS 1.0 [RFC2246] 和 TLS 1.1 [RFC4346] 的安全性被认为不足， 因而无论出于何种原因都不得协商这些版本。¶

实现不得发送兼容 SSL 2.0 版本的 CLIENT-HELLO。 实现不得使用兼容 SSL 2.0 版本的 CLIENT-HELLO 协商 TLS 1.3 或更高版本。不建议实现接受兼容 SSL 2.0 版本的 CLIENT-HELLO 来协商旧版 TLS。¶

实现必须为 ClientHello.legacy_version 和 ServerHello.legacy_version 使用 0x0303。收到其他版本号的 Hello 消息时， 实现必须按照第 4.2.2 节和第 4.2.3 节所述方式中止握手。¶

实现不得发送版本低于 0x0300 的任何记录。 实现不应接受版本低于 0x0300 的任何记录 （不过如果完全忽略记录版本号，可能会无意中接受）。¶

实现不得使用 [RFC6066] 第 7 节中定义的截断 HMAC 扩展，因为它不适用于 AEAD 算法，并且已被证明在某些场景中不安全。¶

F.1. 握手

TLS 握手是一种认证密钥交换（AKE）协议， 旨在同时提供单向身份验证（仅服务器）和 双向身份验证（客户端和服务器）功能。握手完成时， 双方分别输出其所认知的以下值：¶

• 一组“会话密钥”（从主秘密值派生的各种秘密值）， 可从中派生一组工作密钥。请注意，使用早期数据时， 也会从早期秘密值派生秘密值。如下文所述， 这些秘密值具有比从主秘密值派生的秘密值略弱的属性。¶

• 一组密码学参数（算法等）。¶

• 通信双方的身份。¶

我们假设攻击者是主动网络攻击者，这意味着其完全控制 双方通信所使用的网络 [RFC3552]。 即使在这些条件下，握手也应提供下列属性。 请注意，这些属性不一定彼此独立，但反映了 协议使用者的需求。¶

建立相同的会话密钥：

只要握手在每个端点上均成功完成， 握手双方就需要输出同一组会话密钥 （参见 [CK01]，定义 1，第 1 部分）。¶

会话密钥的保密性：

共享会话密钥应仅为通信双方所知， 而不应为攻击者所知（参见 [CK01]，定义 1，第 2 部分）。 请注意，在单向身份验证连接中，攻击者可以与服务器建立 自己的会话密钥，但这些会话密钥与 客户端建立的会话密钥不同。¶

对等方身份验证：

客户端所认知的对等方身份应反映 服务器身份。如果客户端经过身份验证，则服务器所认知的 对等方身份应与客户端身份匹配。¶

会话密钥的唯一性：

任意两个不同的握手都应生成不同且互不相关的 会话密钥。一次握手生成的各个会话密钥也应彼此不同 且相互独立。¶

降级保护：

双方使用的密码学参数应相同， 并且应与对等方在不存在攻击时进行通信所会使用的参数相同 （参见 [BBFGKZ16]，定义 8 和 9）。¶

相对于长期密钥的前向保密性：

如果长期密钥材料（本例中为 基于证书身份验证模式中的签名密钥，或采用非对称密钥交换模式的 PSK 中的外部/恢复 PSK）在握手完成后泄露， 只要会话密钥本身（以及可用于重建会话密钥的所有材料） 已被清除，就不会危及会话密钥的安全性 （参见 [DOW92]）。 特别是，与密钥共享值、共享秘密值以及 TLS 密钥调度中派生的密钥 对应的私钥，也都需要清除， 但 binder_key、resumption_secret 和从 resumption_secret 派生的 PSK 除外。 在“psk_ke”PskKeyExchangeMode 中使用 PSK 时，不满足前向保密性属性。 未能清除原本应为临时或连接专用的密钥或秘密值， 实际上会创建必须加以保护的额外长期密钥。 这些长期密钥泄露（即使发生在握手完成后） 也可能导致连接流量失去保护。¶

密钥泄露冒充（KCI）抗性：

在使用证书进行双向身份验证的连接中， 某一参与方的长期秘密值泄露，不应破坏该参与方在给定连接中 对其对等方的身份验证（参见 [HGFS15]）。例如，如果客户端的签名密钥 泄露，则后续握手中不应能够向该客户端冒充任意服务器。¶

端点身份保护：

服务器身份（证书）应受到保护，避免被动 攻击者获知。客户端身份（证书）应同时受到保护，避免 被动和主动攻击者获知。对于不提供机密性的密码套件， 此属性不成立；虽然本规范未定义任何此类密码套件， 其他文档可能会定义。¶

非正式地说，TLS 1.3 的基于签名模式通过 非对称密钥交换建立唯一、秘密的共享密钥，并由服务器对 握手消息记录的签名进行身份验证，同时通过 MAC 将该密钥 与服务器身份绑定。如果客户端使用证书进行身份验证， 它也会对握手消息记录进行签名，并提供一个与双方身份绑定的 MAC。 [SIGMA] 描述了此类密钥交换协议的设计和 分析。如果每个连接都使用新的非对称密钥， 则输出密钥具有前向保密性。¶

外部 PSK 和恢复 PSK 从一个长期共享秘密值引导出 每个连接唯一的一组短期会话密钥。 此秘密值可能在先前握手中建立。如果使用 PSK 与非对称密钥建立，这些会话密钥也具有前向保密性。 恢复 PSK 的设计使连接 N 计算出的、用于形成 连接 N+1 的恢复秘密值，与连接 N 使用的流量密钥相分离， 从而在连接之间提供前向保密性。 此外，如果在同一连接上建立多个票据， 它们会与不同密钥关联，因此与某个票据关联的 PSK 泄露， 不会导致使用其他票据所关联 PSK 建立的连接泄露。 如果票据存储在数据库中（从而可以删除）， 而不是自行加密，则此属性尤其有意义。¶

前向保密性限制密钥在一个时间方向上的泄露影响 （时间 T2 的密钥泄露不会危及时间 T1 的某些密钥， 其中 T1 < T2）。通过重新执行非对称密钥建立， 可以在另一个方向上获得保护（时间 T1 的泄露不会危及 时间 T2 的密钥）。如果长期身份验证密钥已泄露， 使用非对称密钥建立的完整握手可防御被动攻击者。 如果 resumption_secret 已泄露，使用非对称密钥建立的恢复握手 可防御被动攻击者，而使用非对称密钥建立的完整握手 可防御主动攻击者。如果流量秘密值已泄露， 任何使用非对称密钥建立的握手都可防御主动攻击者。 使用 [RFC7624] 中的术语， 不重新执行非对称密钥建立的前向保密性，无法阻止攻击者进行静态 密钥外泄。在 application_traffic_secret_N 外泄后， 攻击者例如可以被动窃听连接上发送的所有未来数据， 包括使用 application_traffic_secret_N+1、 application_traffic_secret_N+2 等加密的数据。 频繁重新执行非对称密钥建立，会迫使攻击者进行动态密钥外泄 （或内容外泄）。¶

PSK 绑定器值在 PSK 与当前握手之间形成绑定， 并在建立该 PSK 的会话（如果通过 NewSessionTicket 消息建立）与当前会话之间形成绑定。 此绑定会传递性地包含原始握手消息记录， 因为该消息记录会被摘要进生成恢复秘密值的各个值中。 这要求用于生成恢复秘密值的 KDF 和用于计算绑定器的 MAC 都具有抗碰撞性。 有关更多信息，请参阅附录 F.1.1。 注意：绑定器不覆盖其他 PSK 的绑定器值， 不过 Finished MAC 会包含这些值。¶

注意：本规范目前不允许服务器在不基于证书的握手 （例如 PSK）中发送 CertificateRequest 消息。 如果未来放宽此限制， 客户端签名将不会直接覆盖服务器证书。 但是，如果 PSK 通过 NewSessionTicket 建立， 客户端签名将通过 PSK 绑定器传递性地覆盖服务器证书。 [PSK-FINISHED] 描述了针对未与服务器证书绑定的构造的具体攻击 （另请参阅 [Kraw16]）。 当客户端可能与两个不同端点共享同一 PSK/密钥 ID 对时，使用基于证书的客户端身份验证并不安全。 除非其他规范另有规定，否则实现不得 将外部 PSK 与客户端或服务器的基于证书身份验证结合使用。 [RFC8773] 提供了允许这样做的扩展， 但其所受分析程度不及本规范。¶

如果使用导出器，它会生成唯一且秘密的值 （因为这些值由唯一会话密钥生成）。 使用不同标签和上下文计算的导出器在计算上相互独立， 因而无法从一个导出器计算另一个导出器， 也无法从导出值计算会话秘密值。 注意：导出器可以生成任意长度的值； 如果导出器要用作信道绑定，则导出值必须足够大， 以提供抗碰撞性。TLS 1.3 提供的导出器 分别从与早期流量密钥和应用流量密钥相同的握手上下文派生， 因而具有类似的安全属性。请注意，它们 不包含客户端证书；未来希望与客户端证书绑定的应用 可能需要定义包含完整握手消息记录的新导出器。¶

对于所有握手模式，Finished MAC（以及存在时的签名） 都可防止降级攻击。此外，按照第 4.2.3 节所述， 在随机 nonce 中使用某些字节可以检测向早期 TLS 版本的降级。 有关 TLS 1.3 和降级的更多详细信息，请参阅 [BBFGKZ16]。¶

客户端与服务器一旦交换足够的信息来建立共享密钥， 握手的其余部分就会被加密，从而即使计算出的共享密钥 尚未经过身份验证，也可抵御被动攻击者。 由于服务器先于客户端进行身份验证， 客户端可以确保：如果它向服务器进行身份验证， 只会向经过身份验证的服务器披露自身身份。 请注意，实现必须在握手期间使用所提供的记录填充机制， 以避免因长度泄露身份信息。 客户端提供的 PSK 身份未加密， 服务器选择的身份也未加密。¶

F.2. 记录层

记录层依赖握手生成强健的流量秘密值， 可用于派生双向加密密钥和 nonce。 假设这一点成立，并且密钥用于加密的数据量不超过 第 5.5 节所述限制， 则记录层应提供以下保证：¶

机密性：

攻击者不应能够确定给定记录的明文 内容。¶

完整性：

攻击者不应能够构造一条不同于现有记录、 但会被接收方接受的新记录。¶

顺序保护/不可重放性：

攻击者不应能够使接收方接受一条其已经接受过的 记录，也不应能够使接收方在尚未处理记录 N 的情况下 接受记录 N+1。¶

长度隐藏：

对于具有给定外部长度的记录，攻击者不应能够 确定记录中有多少是内容，有多少是填充。¶

密钥更改后的前向保密性：

如果已使用第 4.7.3 节所述的流量密钥更新机制， 并且删除了上一代密钥，则攻陷端点的攻击者 不应能够解密使用旧密钥加密的流量。¶

非正式地说，TLS 1.3 通过使用强密钥对明文进行 AEAD 保护来提供这些属性。AEAD 加密 [RFC5116] 为数据提供机密性和完整性。 不可重放性通过为每条记录使用单独的 nonce 来提供， 该 nonce 从记录序列号派生（第 5.3 节）， 并且双方独立维护序列号；因此， 乱序交付的记录会导致 AEAD 解除保护失败。 为防止不同用户使用同一密钥重复加密相同明文时 发生大规模密码分析（HTTP 中经常出现这种情况）， nonce 通过将序列号与一个随流量密钥一起派生的、 每连接唯一的秘密初始化向量混合而形成。 有关此构造的分析，请参阅 [BT16]。¶

TLS 1.3 中的密钥更新技术（参见第 7.2 节） 遵循 [REKEY] 中讨论的串行生成器构造， 该文表明密钥更新可使密钥支持比不进行更新时更多次数的加密。 这依赖 HKDF-Expand-Label 函数作为伪随机函数（PRF）的安全性。 此外，只要此函数确实是单向的， 就无法计算密钥更改之前的流量密钥（前向保密性）。¶

对于连接的某个流量秘密值泄露后通过该连接传输的数据， TLS 不提供安全性。也就是说，对于流量秘密值， TLS 不提供泄露后安全性/未来保密性/后向保密性。 实际上，获知某个流量秘密值的攻击者可以计算该连接上 所有未来流量秘密值。希望获得此类保证的系统 需要执行新的握手，并使用非对称密钥交换建立新连接。¶

F.3. 流量分析

TLS 容易受到多种基于观察加密数据包长度和时序的 流量分析攻击 [CLINIC] [HCJC16]。 当可能需要区分的消息集合较小时， 这种攻击尤其容易实施，例如视频服务器托管固定内容集合的情况； 但即使在更复杂的场景中，也仍能提供可利用的信息。¶

TLS 不提供针对这种攻击形式的特定防御， 但包含一种供应用使用的填充机制： AEAD 函数所保护的明文由内容加可变长度填充组成， 从而允许应用生成任意长度的加密记录， 以及只含填充的掩护流量，以隐藏传输期间与静默期间的差异。 由于填充与实际内容一起加密， 攻击者无法直接确定填充长度， 但可能通过记录处理期间暴露的时序信道间接测量 （例如观察处理一条记录所需的时间， 或缓慢送入记录以判断哪些记录会触发服务器响应）。 通常，不知道如何消除所有这些信道， 因为即使使用恒定时间的填充移除函数， 也很可能将内容传递给依赖数据的函数。 至少，一个完全恒定时间的服务器或客户端 需要与应用层协议实现密切协作， 包括使该高层协议也以恒定时间运行。¶

注意：强健的流量分析防御可能会因 延迟数据包传输和增加流量而导致性能下降。¶

F.4. 侧信道攻击

总体而言，TLS 没有针对侧信道攻击 （即通过时序等辅助信道攻击通信）的特定防御， 而是将此问题留给相关密码学原语的实现处理。 不过，TLS 的某些功能旨在使编写抗侧信道代码更加容易：¶

• 与使用复合“先计算 MAC 再加密”结构的早期 TLS 版本不同， TLS 1.3 仅使用 AEAD 算法， 从而允许实现使用这些原语的自包含恒定时间实现。¶

• TLS 对所有解密错误统一使用“bad_record_mac”警报， 旨在防止攻击者逐步获知消息各部分的信息。 在此类错误发生时终止连接还可提供额外防护； 新连接将具有不同的密码学材料， 从而阻止需要多次尝试的密码学原语攻击。¶

侧信道信息泄露可能发生在 TLS 之上的层中， 即应用协议以及使用这些协议的应用中。 抵御侧信道攻击取决于应用和应用协议分别确保 机密信息不会无意泄露。¶

F.5. 针对 0-RTT 的 重放攻击

可重放的 0-RTT 数据会给使用 TLS 的应用带来多种安全威胁， 除非这些应用经过专门设计，能在重放情况下保持安全 （最低限度意味着操作是幂等的， 但许多情况下还可能需要更强的条件，例如恒定时间响应）。 潜在攻击包括：¶

• 重复执行会造成副作用的操作 （例如购买商品或转账），从而损害网站或用户。¶

• 攻击者可以存储并重放 0-RTT 消息， 从而相对于其他消息重新排列顺序 （例如将删除操作移动到创建操作之后）。¶

• 放大由缓存等副作用造成的现有信息泄露。 攻击者可以将 0-RTT 消息重放到尚未缓存某个目标资源的 缓存节点，以了解该消息内容的信息， 随后使用单独连接检查该资源是否已被加入缓存。 只要 0-RTT 消息仍可重放，就可以对不同缓存节点重复执行此操作。¶

如果数据可以被大量重放，还会出现其他攻击， 例如反复测量密码学操作的速度。 此外，攻击者可能使速率限制系统过载。 有关这些攻击的进一步说明，请参阅 [Mac17]。¶

最终，服务器有责任保护自身免受使用 0-RTT 数据复制的攻击。 第 8 节中描述的机制 旨在防止 TLS 层重放，但不能完全防止 收到客户端数据的多个副本。 当服务器没有关于客户端的任何信息时， TLS 1.3 会回退到 1-RTT 握手，例如服务器位于不共享状态的 不同集群中，或票据已按照 第 8.1 节所述被删除。 如果应用层协议在这种情况下重新传输数据， 攻击者就可能通过同时向原始集群 （该集群会立即处理数据）和另一个会回退到 1-RTT、 并在应用层重放后处理数据的集群发送 ClientHello， 来诱导消息重复。 此攻击的规模受客户端愿意重试事务的程度限制， 因而只能造成有限数量的重复， 且每个副本在服务器看来都是一个新连接。¶

如果正确实现， 第 8.1 节和第 8.2 节所述机制 可防止具有一致状态的任意集群多次接受 被重放的 ClientHello 及其关联 0-RTT 数据； 对于将单个票据的 0-RTT 使用限制在一个集群的服务器， 给定 ClientHello 及其关联 0-RTT 数据只会被接受一次。 不过，如果状态并非完全一致， 攻击者可能在复制窗口期间使多个数据副本被接受。 由于客户端不知道服务器行为的具体细节， 因此不得在早期数据中发送不适合重放、 且不愿意在多个 1-RTT 连接中重试的消息。¶

应用协议不得在没有定义其用法的配置文件时 使用 0-RTT 数据。该配置文件需要标识哪些消息或 交互可以安全地与 0-RTT 一起使用， 以及当服务器拒绝 0-RTT 并回退到 1-RTT 时应如何处理。¶

此外，为避免误用，除非应用明确请求， TLS 实现不得启用 0-RTT（无论发送还是接受）； 如果服务器拒绝 0-RTT 数据， 除非应用作出指示，否则不得自动重新发送。 服务器端应用可能希望对某些类型的应用流量 实现特殊的 0-RTT 数据处理 （例如中止连接、请求在应用层重新发送数据， 或延迟处理直到握手完成）。 为使应用能够实现此类处理， TLS 实现必须提供一种方式，让应用确定 握手是否已经完成。¶

F.6. PSK 身份暴露

由于实现会通过中止握手来响应无效的 PSK 绑定器， 攻击者可能能够验证给定 PSK 身份是否有效。 具体而言，如果服务器同时接受外部 PSK 握手和基于证书的握手， 有效的 PSK 身份会导致握手失败， 而无效身份则会被直接跳过并导致证书握手成功。 仅支持 PSK 握手的服务器可以通过同样处理以下两种情况， 抵御此类攻击：不存在有效 PSK 身份； 或存在身份，但其绑定器无效。¶

F.7. 跨协议版本共享 PSK

TLS 1.3 对 PSK 采取保守方法，将其与特定 KDF 绑定。 相比之下，TLS 1.2 允许 PSK 与任意哈希函数 以及 TLS 1.2 PRF 一起使用。因此，同时用于 TLS 1.2 和 TLS 1.3 的 任何 PSK，在 TLS 1.3 中只能与一个哈希函数一起使用； 如果用户希望配置单个 PSK，这并非最佳方案。 TLS 1.2 和 TLS 1.3 中的构造不同， 尽管二者都基于 HMAC。目前尚不知道同一 PSK 在两个版本中会生成相关输出的方式， 但对此仅进行过有限分析。 实现可以通过不在 TLS 1.3 和 TLS 1.2 之间复用 PSK， 确保不会出现跨协议相关输出。¶

F.8. 外部 PSK 与 重新路由

TLS 中的外部 PSK 被设计为仅由一个客户端 和一个服务器知晓。不过，如 [RFC9257] 所述， 存在由两个以上实体共享 PSK 的使用场景。 在此类场景中，除被攻陷的组成员可以冒充 任何其他成员这一预期安全弱点外， 恶意非成员还可以在诚实组成员之间重新路由握手， 使它们以非预期方式建立连接 [Selfie]。 [RFC9257] 提供了 外部 PSK 使用建议，包括使用 [RFC9258] 中定义的外部 PSK 导入器， 以防止此类恶意消息重新路由。¶

F.9. 使用自签名证书或 原始公钥时的错误绑定

当 TLS 1.3 使用不包含有效身份的自签名证书 （例如 DTLS-SRTP [RFC5763]） 或原始公钥 [RFC7250] 进行对等方身份验证时，可能容易受到 错误绑定攻击 [MM24]。 可以通过使用“external_id_hash”扩展 [RFC8844] 缓解此风险； 如果仅验证服务器身份，也可以由服务器验证 “server_name”扩展是否与其预期身份匹配。¶

F.10. 针对静态 RSA 的攻击

虽然 TLS 1.3 不使用 RSA 密钥传输， 因而不会直接受到 Bleichenbacher 类攻击 [Blei98]， 但如果 TLS 1.3 服务器还在早期 TLS 版本环境中支持静态 RSA， 则可能在 TLS 1.3 连接中冒充服务器 [JSS15]。 TLS 1.3 实现可以通过在所有 TLS 版本中禁用静态 RSA 支持 来防止此攻击。原则上，实现还可以 使用不同 keyUsage 位，将静态 RSA 解密证书 与 RSA 签名证书分开； 但此技术依赖客户端拒绝接受 使用未设置 digitalSignature 位的证书中密钥所生成的签名， 而许多客户端并不强制执行此限制。¶