TLS 1.3 Compliance Requirements

一. Mandatory-to-Implement Cipher Suites

TLS 1.3 中有一些密码套件是强制必须实现的。

在本文下面的描述中,“必须” 代表 MUST,“应该”代表 SHOULD。请读者注意措辞。

在没有应用程序配置文件标准指定的情况下,除此以外都需要满足以下要求:

符合 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] 的密钥交换。

二. Mandatory-to-Implement Extensions

TLS 1.3 中有一些扩展是强制必须实现的。

如果没有另外指定的应用程序配置文件标准,符合 TLS 标准的应用程序必须实现以下 TLS 扩展:

所有的实现方必须在协商时发送和使用这些扩展:

  • 所有 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 包含其 body 中包含 0x0304 的 "supported_versions" 扩展,则客户端被认为会尝试使用此规范进行协商。这样的 ClientHello 消息必须满足以下要求:

  • 如果不包含 "pre_shared_key" 扩展名,则它必须包含 "signature_algorithms" 扩展名和 "supported_groups" 扩展名。

  • 如果包含 "supported_groups" 扩展名,则它必须还包含 "key_share" 扩展,反之亦然。允许空的 KeyShare.client_shares 向量。

Server 如果接收到不符合上述这些要求的 ClientHello 消息,必须立即使用 "missing_extension" alert 消息中止握手。

此外,所有实现方必须支持,能够使用它的应用程序使用 "server_name" 扩展。Server可能要求 Client 发送有效的 "server_name" 扩展名。需要此扩展的 Server 应该通过使用 "missing_extension" alert 消息终止连接来响应缺少 "server_name"扩展名的 ClientHello。

三. Protocol Invariants

本节介绍 TLS 终端和中间件必须遵循的不变的东西。它也适用于早期版本的 TLS。

TLS 设计的宗旨是安全且能兼容性地扩展。较新的 Client 或 Server 在与较新的对等方通信时,应协商最优选的公共参数。TLS 握手提供降级保护: 中间件在较新的 Client 和较新的 Server 之间传递流量而不终止 TLS ,中间件不能影响握手(参见附录 E.1)。同时,部署协议应该以不同的速率去更新,因此较新的 Client 或 Server 可以继续支持较旧的参数,这将允许它与较旧的终端进行互操作(向下兼容)。

为此,实现方必须正确处理可扩展字段:

  • 发送 ClientHello 的 Client 必须支持其中公布的所有参数。否则,Server 可能无法通过选择其中一个参数进行互操作。

  • 接收 ClientHello 的 Server 必须正确地忽略所有无法识别的密码套件,扩展和其他参数。否则,它可能无法与较新的 Client 互操作。在 TLS 1.3 中,接收 CertificateRequest 或 NewSessionTicket 的 Client 也必须忽略所有无法识别的扩展。

  • 能终止 TLS 连接的中间件必须表现为兼容的 TLS 的 Server(对原始的 Client 来说),包括具有 Client 愿意接受的证书,这个中间件也能作为兼容的 TLS 的 Client(对原始的 Server 来说),包括验证原始 Server 的证书。特别是,它必须生成自己的 ClientHello,其中只包含它理解的参数,它必须生成一个新的 ServerHello 随机值,而不是转发终端的值。

请注意,TLS 的协议要求和安全性分析仅适用于两个分开的连接。如何安全地部署 TLS terminator 需要额外的安全注意事项,这超出了本文档的讨论范围。

  • 如果中间件转发了自己不能理解的 ClientHello 参数,它不允许处理 ClientHello 之外的任何消息。它必须转发所有的未经修改的后续流量。否则,它可能无法与较新的 Client 和 Server 进行互操作。

转发的 ClientHellos 可能包含中间件不支持的功能,因此响应体里面可能包括中间件无法识别的未来 TLS 新添加的特性。这些新添加的特性可能会改变 ClientHello 以外的任何消息。特别是,ServerHello 中发送的值可能会变,ServerHello 格式可能会变,TLSCiphertext 格式也可能会变。

TLS 1.3 的设计受到了广泛部署却不符合 TLS 规范的中间件的限制(见附录 D.4);但是,它并没有放松不变的东西。这些中间件继续不符合规范。


Reference:

RFC 8446

GitHub Repo:Halfrost-Field

Follow: halfrost · GitHub

Source: https://halfrost.com/TLS_1.3_Compliance_Requirements/