摘要

  • 对 TLS 1.2 和 DTLS 1.2，RFC 10015 要求客户端不得提供、服务器不得选择若干有限域 Diffie–Hellman 与静态 RSA 密钥交换套件；静态 ECDH 及固定 DH 客户端证书类型则仍是“不应”。两种规范力度不能被自动化系统抹平。
  • IANA 的 D 是标准政策证据，不是部署证据。要声称“已经禁用”，还须把有效配置、终止点清单、重载记录、主动探测、协商遥测、例外到期与旧客户端迁移串成一张弃用闭环凭证。

某天凌晨，密码套件登记表完成更新。第二天早上，合规大盘上的对应项目变成绿色。与此同时，一台由旧团队维护的 DTLS 终止设备仍在使用几个月前加载的策略。表格与设备都没有撒谎；错误发生在有人把前者当成了后者的证明。

RFC 10015 是 2026 年 7 月发布的 IETF 标准轨文档。它更新 TLS 1.2、DTLS 1.2 相关规范与安全建议，明确哪些旧式密钥交换不再应被提供或选择。文档并未报告扫描结果、厂商移除进度、网络采用率或任何具体服务的配置状态。

这条边界对安全自动化尤其重要。IANA 数据适合机器读取：登记项变化可以触发规则、工单和检查。但是，从“登记表不再推荐”直接跳到“互联网端点已禁用”，中间跨过了代码、默认值、本地配置、渲染结果、进程状态、边缘发布以及实际握手等多个独立控制面。

先保留规范里的差别

RFC 10015 不是把所有带有 DH 或 RSA 字样的机制装进一个废纸篓。在 TLS 1.2 和 DTLS 1.2 中，客户端对非临时有限域 DH 套件是 MUST NOT，服务器不得选择；对临时有限域 DHE 套件也是同样的 MUST NOT。静态 RSA 密钥交换套件同样进入“不得提供、不得选择”的范围。

静态 ECDH 的措辞不同，仍然是 SHOULD NOT。文档涉及的固定 DH 客户端证书类型也是 SHOULD NOT。这不代表它们安全，也不等于可以随意忽略；它意味着在极特殊情况下偏离要求仍须给出可审查的理由。若控制系统只保留“弃用”一个标签，审计者就看不到某项是绝对禁令，还是带有严格例外语义的建议。

版本也不能省略。RFC 8996 已经弃用 TLS 1.0 与 1.1；RFC 5246 定义 TLS 1.2，RFC 8446 则重新设计 TLS 1.3。RFC 10015 明确指出，有限域临时 DH 可用于 TLS 1.3；TLS 1.2 的问题不能被偷换为“任何版本的 FFDHE 都禁止”。RFC 7919 所规定的协商群组仍是理解这一版本边界的必要背景。

“静态 RSA 密钥交换”也不是“所有 RSA”。服务器可以使用 RSA 证书与 RSA 签名，而不采用静态 RSA 密钥传输。若资产查询只问证书算法，得到的只是认证材料清单，并不能回答握手选择了什么密钥交换。

标准收紧并非词语清理。缺少前向保密意味着长期密钥日后泄露时，历史会话可能被追溯解密；复用有限域 DH 密钥会带来计时与群组选择风险；复用 ECDH 密钥暴露于无效曲线、侧信道与故障类问题；静态 RSA 则长期面对 Bleichenbacher 类漏洞及跨协议、密钥复用风险。RFC 9325 与 RFC 9847 共同说明，部署建议必须随已知攻击面更新，而不能因为旧实现仍可互通就永久冻结。

D 到底证明了什么

IANA TLS 参数登记表 已把相关密码套件以及四个 ClientCertificateType 标为 D，并指向 RFC 10015。这里的 D 表示 discouraged，也就是不鼓励使用；其具体规范强度需要回到引用文档，可能对应 MUST NOT，也可能对应 SHOULD NOT。

因此，D 能够证明的是登记表当前的建议状态。它足以触发配置审查、软件清单检查和迁移任务，却不能单独证明：

  1. 密码库已经删除实现；
  2. 产品默认配置已经关闭能力；
  3. 本地策略已去除相应套件；
  4. 正在运行的进程已加载新策略；
  5. 所有 SNI、监听端口、代理、负载均衡器和区域边缘均已发布；
  6. 客户端不再提供；
  7. 服务器不再选择；
  8. 例外路径或回滚镜像不会重新启用。

这些项目的责任人、更新时间与证据形式都不相同。用一个绿色图标覆盖它们，实际是在丢弃最关键的治理信息。

能力、提供、选择、观测不是同一个状态

“实现仍有能力”不代表握手一定会提供；“配置中出现名称”不代表服务器最终会选；“扫描未见”也不代表所有策略路径均不可能发生。

现代客户端在正常连接时往往不会提供被禁止的套件，因此一次成功握手只能证明双方找到了更好的共同选项。更有力的负向探测，是让受控客户端只提供目标套件，并确认服务器拒绝连接。但这项结论仍只适用于实际到达的地址、SNI、端口、传输协议和当时的配置版本。

RFC 9147 所定义的 DTLS 1.3 也提醒运营者：仅扫描 TCP 上的 TLS 监听器，不能替 UDP 上的 DTLS 暴露面结案。同一个域名可能在 CDN、区域入口、源站和内部服务网格处多次终止。全局配置声明若没有终止点清单，就没有可靠分母。

建立“弃用闭环凭证”

每个服务暴露面应有一份 弃用闭环凭证。第一栏记录规范对象：RFC、IANA 标识、协议版本、密钥交换家族以及 MUST NOT 或 SHOULD NOT。这样既不会误删 TLS 1.3 中仍允许的 FFDHE，也不会把静态 ECDH 的例外语义伪装成静态 RSA 的同等禁令。

第二栏记录实际控制点：配置权威来源、提交版本、渲染后的有效策略、软件或设备版本、监听器、SNI、地址、端口、传输协议、前置代理及终止位置。对于分布式入口，“已更新统一策略”只是意图，不能代替每个执行点。

第三栏记录生效过程：重启、热加载、策略刷新或托管发布的时间；变更单；目标数量；成功、失败与仍待处理的实例；回滚版本。文件已经改过，与进程正在执行新策略，是两种不同证据。

第四栏记录行为验证：只提供禁用套件时是否被拒绝；提供可接受替代项时实际选中什么；客户端提供与服务器选择在多长窗口内是否仍被遥测观察到；采样缺口在哪里。凭证必须保留“没有观测到”和“无法发生”的区别。

最后一栏处理例外与依赖者。它写清旧客户端、业务用途、范围、补偿控制、批准人、责任人、到期日、退出条件和迁移结果。没有到期日的兼容例外并不是临时桥梁，而是一套平行政策。

这张凭证是 Daniel Kade 提出的治理方法，不是 RFC 10015 新增的协议要求。它要解决的是一种常见错位：机器能迅速读到标准变化，却不能因此假装机器已经改完了生产环境。

让自动化只说它能证明的话

更可靠的状态词应当逐层表达：“登记表已弃用”“源配置已移除”“进程重载已验证”“负向探测已拒绝”“在明确覆盖范围内未见选择”“例外已到期并关闭”。只有相关终止路径全部有证据时，系统才可输出“已禁用”。

这种精度也会缩短故障定位。一旦再次发现禁用套件被选择，团队可以查明问题在规则源、配置渲染、发布、监听器盘点、例外管理，还是依赖客户端迁移。一个笼统的合规位无法给出这条因果链。

标准机构已经完成了它能完成的部分：明确哪些 TLS 1.2 与 DTLS 1.2 行为不再符合安全要求。接下来的问题属于运行者——究竟是哪一个端点仍有机会作出旧选择，以及谁能拿出关闭这种机会的证据。

来源