【RFC5246 TLS 协议1.2】（全文翻译+小部分缩译）

原文 rfc5246 (ietf.org) The Transport Layer Security (TLS) Protocol Version 1.2

【会注明缩译部分】

概要
本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（STD 1）。
本文档规定了传输层安全 (TLS) 协议的 1.2 版本。 TLS 协议提供 Internet 上的通信安全。该协议允许客户端/服务器应用程序以一种旨在防止窃听、篡改或消息伪造的方式进行通信。

目录

   1.  简介
      1.1.需求术语（略）
      1.2.与 TLS 1.1 的主要区别
   2. 目标
   3. 本文的目标
   4. 演示语言
      4.1.基本块大小
      4.2.Miscellaneous
      4.3.向量
      4.4.数字
      4.5.枚举
      4.6.构造类型
           4.6.1.变体（省略）
      4.7.密码属性（省略）
      4.8.常数（省略）
   5. HMAC 和伪随机函数
   6. TLS 记录协议
      6.1.连接状态
      6.2.记录层
           6.2.1.分片
           6.2.2.记录压缩和解压
           6.2.3.记录有效负载保护
                  6.2.3.1.空或标准流密码
                  6.2.3.2. CBC 块密码
                  6.2.3.3. AEAD 密码
      6.3.密钥计算
   7. TLS 握手协议
      7.1.更改密码规范协议
      7.2.警报协议
           7.2.1.关闭警报
           7.2.2.错误警报
      7.3.握手协议概述
      7.4.握手协议
           7.4.1. Hello消息
                  7.4.1.1. Hello请求
                  7.4.1.2. 客户端Hello
                  7.4.1.3. 服务器Hello
                  7.4.1.4. Hello扩展
                           7.4.1.4.1. 签名算法
           7.4.2.服务器证书
           7.4.3.服务器密钥交换消息
           7.4.4.证书申请
           7.4.5.服务器Hello完成
           7.4.6.客户端证书
           7.4.7.客户端密钥交换消息
                  7.4.7.1. RSA 加密的 Premaster 秘密消息
                  7.4.7.2.客户端 Diffie-Hellman 公共值
           7.4.8.证书验证
           7.4.9.完成
   8. 密码计算
      8.1.计算主密钥
           8.1.1. RSA
           8.1.2. Diffie-Hellman
   9. 强制密码套件 (Cipher Suite)
   10. 应用数据协议
   11. 安全考虑
   12. IANA 考虑
附录 A. 协议数据结构和常量值 （后文暂略）
      A.1.记录层
      A.2.更改密码规范消息
      A.3.警报消息
      A.4.握手协议
           A.4.1.Hello消息
           A.4.2.服务器身份验证和密钥交换消息
           A.4.3.客户端身份验证和密钥交换消息
           A.4.4.握手结束消息
      A.5.密码套件(Cipher Suite)
      A.6.安全参数
      A.7.对 RFC 4492 的更改
   附录 B. 词汇表
   附录 C. 密码套件定义
   附录 D. 实施说明
      D.1.随机数生成和播种
      D.2.证书和认证
      D.3.密码套件
      D.4.实施陷阱
   附录 E. 向后兼容性
      E.1.与 TLS 1.0/1.1 和 SSL 3.0 的兼容性
      E.2.与 SSL 2.0 的兼容性
      E.3.避免中间人版本回滚
   附录 F. 安全分析
      F.1.握手协议
           F.1.1.身份验证和密钥交换
                  F.1.1.1.匿名密钥交换
                  F.1.1.2. RSA 密钥交换和认证
                  F.1.1.3.带有身份验证的 Diffie-Hellman 密钥交换
           F.1.2.版本回滚攻击
           F.1.3.检测对握手协议的攻击
           F.1.4.恢复会话
      F.2.保护应用程序数据
      F.3.显式向量
      F.4.复合密码模式的安全性
      F.5.拒绝服务
      F.6.最后笔记
   规范参考
   参考资料
   工作组信息
   贡献者

1. 简介

TLS 协议的主要目标是在两个通信应用程序之间提供隐私和数据完整性。该协议由两层组成：TLS 记录协议和 TLS 握手协议。在最低级别，位于某些可靠传输协议（例如 TCP [TCP]）之上的是TLS 记录协议。TLS 记录协议提供了具有两个基本属性的连接安全性：

- 连接是私有的。对称加密用于数据加密（例如，AES [AES]、RC4 [SCH] 等）。这种对称加密的密钥是为每个连接唯一生成的，并且基于另一个协议（例如 TLS 握手协议）协商的密钥。记录协议也可以在不加密的情况下使用。

- 连接可靠。消息传输包括使用密钥 MAC 的消息完整性检查。安全哈希函数（例如，SHA-1 等）用于 MAC 计算。记录协议可以在没有 MAC 的情况下运行，但通常仅用于此模式，而另一个协议使用记录协议作为协商安全参数的传输。

TLS Record Protocol 用于封装各种更高级别的协议。一个这样的封装协议，即 TLS 握手协议，允许服务器和客户端在应用程序协议传输或接收其第一个数据字节之前相互验证并协商加密算法和密钥。 TLS 握手协议提供了具有三个基本属性的连接安全性：

- 可以使用非对称或公钥，密码学（例如，RSA [RSA]、DSA [DSS] 等）验证对等方的身份。这种身份验证可以是可选的，但通常需要至少一个对等端。

- 共享密钥(shared secret)的协商是安全的：窃听者无法获得协商的密钥，并且对于任何经过身份验证的连接，即使攻击者可以将自己置于连接中间，也无法获得该密钥。

- 协商是可靠的：任何攻击者都不能在不被通信双方检测到的情况下修改协商通信。

TLS 的优势之一是它独立于应用程序协议。更高级别的协议可以透明地叠加在 TLS 协议之上。然而，TLS 标准并没有指定协议如何通过 TLS 增加安全性；关于如何启动 TLS 握手以及如何解释交换的身份验证证书的决定留给了运行在 TLS 之上的协议的设计者和实现者的判断。

1.1 需求术语（略）

1.2.与 TLS 1.1 的主要区别

本文档是 TLS1.1 [TLS1.1] 协议的修订版，其中包含改进的灵活性，特别是对于加密算法的协商，密码学算法。主要的变化是：
- 伪随机函数 (PRF) 中的 MD5/SHA-1 组合已替换为密码套件指定的 PRF。本文档中的所有密码套件都使用 P_SHA256。
- 数字签名元素中的 MD5/SHA-1 组合已替换为单个哈希。签名元素现在包含一个明确指定使用的哈希算法的字段。
- 对客户端和服务器指定他们将接受哪些散列和签名算法的能力进行大量清理。请注意，这也放宽了先前版本的 TLS 对签名和哈希算法的一些限制。
- 增加了对具有附加数据模式的认证加密的支持。
- TLS 扩展定义和 AES 密码套件从外部 [TLSEXT] 和 [TLSAES] 合并。
- 更严格地检查 EncryptedPreMasterSecret 版本号。
- 收紧了多项要求。
- verify_data 长度现在取决于密码套件（默认仍然是 12）。
- 清理了 Bleichenbacher/Klima 攻击防御的描述。
- 在许多情况下，必须当下发送警报。
- 在certificate_request 之后，如果没有可用的证书，客户端现在必须发送一个空的证书列表。
- TLS_RSA_WITH_AES_128_CBC_SHA 现在是实现密码套件的必备条件。
- 添加了 HMAC-SHA256 密码套件。
- 删除了 IDEA 和 DES 密码套件。它们现在已被弃用，并将在单独的文档中记录。
- 对 SSLv2 向后兼容的 hello 的支持现在是 MAY，而不是 SHOULD，向它发送 SHOULD NOT。支持将来可能会变成不应该。
- 向演示语言添加了有限的“失败”，以允许多个外壳臂具有相同的编码。
- 添加了实施陷阱部分
- 通常的澄清和编辑工作。

2. 目标

TLS 协议的目标按优先级顺序如下：
1. 密码安全性：应该使用 TLS 来建立两方之间的安全连接。
2. 互操作性：独立程序员应该能够开发利用 TLS 的应用程序，这些应用程序可以在不了解彼此代码的情况下成功交换加密参数。
3. 可扩展性：TLS 寻求提供一个框架，可以根据需要将新的公钥和批量加密方法合并到其中。这也将实现两个子目标：防止需要创建新协议（并冒着引入可能的新弱点的风险）和避免需要实施全新的安全库。
4. 相对效率：加密操作往往是高度 CPU 密集型的，尤其是公钥操作。为此，TLS 协议包含了一个可选的会话
缓存方案以减少需要从头开始建立的连接数。此外，还注意减少网络活动。

3. 本文的目标

本文档和 TLS 协议本身基于 Netscape 发布的 SSL 3.0 协议规范。此协议与 SSL 3.0 之间的差异并不显着，但它们足够重要，以至于 TLS 和 SSL 3.0 的各种版本无法互操作（尽管每个协议都包含一种机制，通过该机制，实现可以回退到以前的版本）。本文档主要面向将要实施该协议的读者以及对其进行加密分析的读者。编写规范时考虑到了这一点，旨在反映这两个群体的需求。出于这个原因，许多与算法相关的数据结构和规则都包含在正文中（而不是在附录中）【此处代码部分较多，进行缩译】，以便于访问它们。

本文档不打算提供服务定义或接口定义的任何细节，尽管它确实涵盖了某些策略领域，因为它们是维护可靠安全性所必需的。

4. 演示语言

本文档处理外部表示中的数据格式。 将使用以下非常基本且有点随意定义的表示语法。 语法在其结构中来自多个来源。 尽管它在语法上类似于编程语言“C”，在语法和意图上类似于 XDR [XDR]，但绘制太多相似之处是有风险的。 这种表示语言的目的只是为了记录 TLS； 没有超出该特定目标的一般应用。

4.1. 基本块大小

明确指定了所有数据项的表示。 基本数据块大小为 1 个字节（即 8 位）。 多字节数据项是字节的串联，从左到右，从上到下。 从字节流中，一个多字节项（示例中的数字）由以下方式形成（使用 C 符号）：

这种多字节值的字节顺序是常见的网络字节顺序或大端格式。

4.2. Miscellaneous

注释以“/*”开头，以“*/”结尾。
可选组件通过将它们括在“[[ ]]”双括号中来表示。

包含未解释数据的单字节实体属于不透明类型。

4.3. 向量

向量（单维数组）是同构数据元素的流。 向量的大小可以在文档时指定，也可以在运行时未指定。 在任何一种情况下，长度都声明了向量中的字节数，而不是元素数。 指定新类型 T'（即 T 类型的固定长度向量）的语法是

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

在下面的例子中，Datum被定义为协议不解释的三个连续字节，而Data是三个连续的Datum，总共消耗九个字节。

可变长度向量是通过使用符号 <floor..ceiling> 指定合法长度的子范围来定义的。 当这些被编码时，实际长度在字节流中向量的内容之前。 长度将采用数字的形式，消耗尽可能多的字节以保持向量的指定最大（上限）长度。 实际长度字段为零的可变长度向量称为空向量。

在以下示例中，mandatory 是一个必须包含 300 到 400 个字节的 opaque 类型的向量。 它永远不能是空的。
实际长度字段占用两个字节，一个 uint16，足以表示值 400（参见第 4.4 节）。 另一方面，longer 可以表示最多 800 个字节的数据，或 400 个 uint16 元素，并且可能为空。 它的编码将包括一个预先添加到向量的两字节实际长度字段。 编码向量的长度必须是单个元素长度的偶数倍（例如，uint16 的 17 字节向量将是非法的）。

4.4. 数字

基本数字数据类型是无符号字节 (uint8)。所有较大的数字数据类型都由固定长度的字节序列组成，如第 4.1 节所述，并且也是无符号的。以下数字类型是预定义的。

规范中这里和其他地方的所有值都以网络字节（大端）顺序存储；由十六进制字节 01 02 03 04 表示的 uint32 等效于十进制值 16909060。

请注意，在某些情况下（例如，DH 参数）需要将整数表示为不透明向量。在这种情况下，它们被表示为无符号整数（即，即使设置了最高有效位，也不需要前导零八位字节）。

4.5. 枚举

另一种稀疏数据类型称为枚举。枚举类型的字段只能采用定义中声明的值。
每个定义都是不同的类型。只能分配或比较相同类型的枚举。枚举的每个元素都必须分配一个值，如以下示例所示。
由于枚举的元素没有排序，因此可以按任何顺序为它们分配任何唯一值。

枚举在字节流中占据的空间与其最大定义的序数值一样多。以下定义将导致使用一个字节来承载颜色类型的字段。
枚举 { 红色（3），蓝色（5），白色（7）} 颜色；
可以选择指定一个没有关联标签的值来强制定义宽度而不定义多余的元素。

在以下示例中，Taste 将消耗数据流中的两个字节，但只能假定值 1、2 或 4。
枚举 { 甜（1），酸（2），苦（4），（32000）} 味道；
枚举元素的名称在定义的类型范围内。在第一个示例中，对枚举的第二个元素的完全限定引用将是 Color.blue。如果任务的目标明确指定，则不需要此类资格。

      颜色颜色 = Color.blue; /* 过度指定，合法 */
      颜色颜色=蓝色； /* 正确，类型隐式 */

对于从未转换为外部表示的枚举，可以省略数字信息。

      枚举{低，中，高}数量；

4.6.构造类型

为方便起见，可以从原始类型构造结构类型。每个规范都声明了一个新的、唯一的类型。定义的语法很像 C 的语法。

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

 

此处省略（代码请详见原文）

 

5. HMAC 和伪随机函数

TLS 记录层使用密钥消息身份验证代码 (MAC) 来保护消息完整性。本文档中定义的密码套件使用称为 HMAC 的结构，在 [HMAC] 中进行了描述，该结构基于散列函数。如果需要，其他密码套件可以定义它们自己的 MAC 结构。

此外，为了密钥生成或验证的目的，需要一种结构来将密钥扩展为数据块。
这个伪随机函数 (PRF) 将密钥、种子和识别标签作为输入，并产生任意长度的输出。

在本节中，我们定义了一个基于 HMAC 的 PRF。当协商 TLS 1.2 时，此具有 SHA-256 散列函数的 PRF 用于本文档和本文档之前发布的 TLS 文档中定义的所有密码套件。新的密码套件必须明确指定一个 PRF，并且通常应该使用带有 SHA-256 或更强大的标准哈希函数的 TLS PRF。

首先，我们定义了一个数据扩展函数 P_hash(secret, data)，它使用单个散列函数将秘密和种子扩展为任意数量的输出：

P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) + HMAC_hash(secret, A(2) + seed) + HMAC_hash(secret, A(3) + seed) + ...

其中 + 表示串联。

A() 定义为：
      A(0) = 种子
      A(i) = HMAC_hash(secret, A(i-1))

P_hash 可以根据需要迭代多次，以产生所需数量的数据。例如，如果使用 P_SHA256 创建 80 字节的数据，则必须迭代 3 次（通过 A(3)），创建 96 字节的输出数据；最终迭代的最后 16 个字节将被丢弃，留下 80 个字节的输出数据。

TLS 的 PRF 是通过将 P_hash 应用于秘密来创建的：
PRF（秘密，标签，种子）= P_<hash>（秘密，标签+种子）

标签是一个 ASCII 字符串。它应该以给出的确切形式包含，没有长度字节或尾随空字符。
例如，标签“slithy toves”将通过散列以下字节来处理：

      73 6C 69 74 68 79 20 74 6F 76 65 73

6. TLS 记录协议

TLS 记录协议是一个分层协议。在每一层，消息可能包括长度、描述和内容字段。记录协议接收要传输的消息，将数据分段为可管理的块，可选地压缩数据，应用 MAC，加密并传输结果。接收到的数据经过解密、验证、解压缩、重组，然后传送到更高级别的客户端。

本文档描述了四种使用记录协议的协议：握手协议、警报协议、更改密码规范协议和应用程序数据协议。为了允许 TLS 协议的扩展，记录协议可以支持额外的记录内容类型。如第 12 节所述，新记录内容类型值由 IANA 在 TLS 内容类型注册表中分配。

除非由某些扩展协商，否则实现不得发送本文档中未定义的记录类型。如果 TLS 实现接收到意外的记录类型，它必须发送一个unexpected_message 警报。

任何设计用于 TLS 的协议都必须经过精心设计，以应对针对它的所有可能的攻击。实际上，这意味着协议设计者必须了解 TLS 提供和不提供哪些安全属性，并且不能安全地依赖后者。

请特别注意，记录的类型和长度不受加密保护。如果此信息本身很敏感，应用程序设计人员可能希望采取措施（填充、覆盖流量）以最大程度地减少信息泄漏。

6.1.连接状态