用于防止协议降级攻击的TLS备用信号加密套件值（SCSV），RFC7507

最新推荐文章于 2023-11-30 17:48:02 发布

The_Hungry_Brain

最新推荐文章于 2023-11-30 17:48:02 发布

阅读量3k

点赞数

分类专栏： TLS OpenSSL

本文链接：https://blog.csdn.net/u010129119/article/details/77665925

版权

OpenSSL 同时被 2 个专栏收录

10 篇文章 1 订阅

订阅专栏

TLS

3 篇文章 0 订阅

订阅专栏

为了解决传统服务器的互操作性问题，许多TLS客户端实现不依赖于TLS协议版本协商机制，而是在初始握手尝试失败时有意使用降级协议重新连接。这样的客户端可能会退回到它们宣布版本低至TLS 1.0（或甚至其前身的安全套接层（SSL）3.0））的连接，作为最高支持版本。

虽然这种后备重试可能是与实际遗留服务器连接的有用的最后手段，但主动攻击者可能会利用降级策略来削弱连接的加密安全性。此外，由于网络故障引起的握手错误也可能被误解为与旧服务器的交互，并导致协议降级。

所有不必要的协议降级是不希望的（例如，如果客户端和服务器实际上都支持TLS 1.2，则从TLS 1.2到TLS 1.1）;当结果是通过降级到SSL 3.0而导致TLS扩展功能的丢失时，它们可能特别有害。

本文档定义了一个SCSV，可用于通过让客户端指示当前连接尝试仅仅是一个后备，并通过让服务器返回致命警报（如果它检测到），则可以防止客户端与服务器之间意外的协议降级不适当的回退。（警报并不一定表示有意降级攻击，因为网络故障也可能导致不适当的后备重试。）

本文档中定义的备用SCSV不适合替代正确的TLS版本协商。 TLS实现需要正确处理TLS版本协商和可扩展性机制，以避免与回退重试相关的安全问题和连接延迟。

1、协议值：

这个文档定义了一个新的TLS加密套件值，

TLS_FALLBACK_SCSV {0x56, 0x00}

这是一个SCSV，即它实际上并不对应一套密码系统，并且在握手中永远不能被服务器选择; 相反，它在客户端Hello消息中的存在作为从客户端到服务器的向后兼容信号。

本文档还在TLS Alert Registry [RFC5246]中分配了一个新的警报值：

enum {
    /* ... */
    inappropriate_fallback(86),
    /* ... */
    (255)
} AlertDescription;

此警报仅由服务器生成，如第3节所述。它总是致命的。

2、服务器行为

本节指定从ClientHello.cipher_suites中的客户端接收TLS_FALLBACK_SCSV加密套件时的服务器行为。

如果ClientHello.cipher_suites中出现TLS_FALLBACK_SCSV，并且服务器支持的最高协议版本高于ClientHello.client_version中指示的版本，则服务器必须以致命的illegal_fallback警报作出响应（除非它由于致命的protocol_version警报而响应，因为版本号为 ClientHello.client_version不受支持）。该警报的记录层版本号必须设置为ClientHello.client_version（如果服务器持续握手时为Server Hello消息）或客户端使用的记录层版本号。

否则（TLS_FALLBACK_SCSV不出现或出现，客户端的协议版本至少是服务器支持的最高协议版本），则服务器将照常进行握手。

（服务器支持协议版本，如果响应适当的客户端Hello消息，服务器将使用ServerHello.server_version，如果实现了特定的协议版本，但完全被服务器设置禁用，则不被认为是支持的。例如，如果实现的最高协议版本是TLS 1.2，但是服务器操作员已禁用此版本，则TLS 1.1 Client Hello（TLS_FALLBACK_SCSV）不保证使用不适当的警告进行响应）。

3、客户端行为

TLS_FALLBACK_SCSV密码套件值用于重复使用降级协议的连接尝试的客户端（执行“后退重试”），以解决与旧版服务器的互操作性问题。

如果客户端发送的ClientHello.client_version包含的值低于客户端支持的最新（最高值）版本，则应在ClientHello.cipher_suites中包含TLS_FALLBACK_SCSV加密套件值;有关本建议的安全考虑，请参阅第6节。（客户端应该将TLS_FALLBACK_SCSV放在实际打算协商的所有密码套件之后）

作为上述的例外，当客户端打算恢复会话并将ClientHello.client_version设置为为该会话协商的协议版本时，它不得在ClientHello.cipher_suites中包含TLS_FALLBACK_SCSV。（在这种情况下，假设客户端已经知道服务器支持的最高协议版本：请参见[RFC5246]的附录E.1。）

如果客户端将ClientHello.client_version设置为最高支持的协议版本，则它不得在ClientHello.cipher_suites中包含TLS_FALLBACK_SCSV。

（如果客户端通常尝试在握手中使用协议版本，则协议版本如果客户端设置实现了特定协议版本但完全禁用，则不被视为支持，例如，如果实现的最高协议版本为TLS 1.2但用户已禁用此版本，预期TLS 1.1握手，不保证发送TLS_FALLBACK_SCSV。）

回退重试可能是由于网络故障等事件引起的，ClientHello.cipher_suites中包含TLS_FALLBACK_SCSV的客户端可能会收到一个不适当的反向警报，表示服务器支持更高的协议版本。因此，如果客户端打算使用重试来解决网络故障问题，则应该重试其支持的最高版本。

如果客户端跟踪特定服务器明显支持的最高协议版本，以便稍后在ClientHello.client_version中使用，那么如果客户端从该服务器接收到一个不适当的警告，则必须清除记忆最高的支持协议版本。（没有警报，这是一个好主意 - 但在本文档的范围之外 - 客户端在超时后清除该状态，因为服务器的最高协议版本可能会随时间而变化）。

对于使用客户端TLS False启动[false-start]的客户端，重要的是要注意，TLS_FALLBACK_SCSV机制无法保护客户端发送的第一轮应用程序数据：请参阅[false]的安全注意事项（第6节） -开始]。

操作事项：

如果旧版服务器实现不是“versiontolerant”（无法正确处理较新协议版本的客户端Hello消息），则更新旧服务器集群以同时添加对较新协议版本的支持并支持TLS_FALLBACK_SCSV可能会出现并发症：与旧服务器互操作所需的后退重试节点可能被更新的服务器节点拒绝。更新服务器集群连续两个步骤使安全：首先，更新服务器软件，但保持最高支持版本不变（通过禁用服务器设置中的较新版本）; 那么在所有遗留（版本不允许）实现被删除之后，更改服务器设置以允许新的协议版本。

安全考虑：

第4节不要求客户端实现在任何特定情况下发送TLS_FALLBACK_SCSV，它只是推荐它;行为可以根据客户的安全需求进行调整。重要的是要记住，省略TLS_FALLBACK_SCSV可以降级攻击，因此实现者必须考虑ClientHello.client_version给出的协议版本是否仍然提供可接受的保护级别。例如，在初始部署新协议版本时（可能需要预期某些互操作性问题），在出现问题的情况下，顺利地退回到以前的协议版本可能更可能根本无法连接：此特定协议降级步骤可以省略TLS_FALLBACK_SCSV。但是，强制建议在降级到SSL 3.0时发送TLS_FALLBACK_SCSV，因为SSL 3.0中的密码块链接（CBC）加密套件具有无法通过实施方法解决的弱点，例如稍后（TLS）协议版本中的其余缺陷。