摘要

  • RFC 10015 要求 TLS/DTLS 1.2 客户端不得提供、服务器不得选择 FFDH、FFDHE 与 RSA 密钥交换套件；静态 ECDH 使用的是较弱但仍严肃的 SHOULD NOT。
  • 规则严格受版本与功能边界约束：TLS/DTLS 1.3 仍可使用 FFDHE；RSA 证书也可以认证合规的临时密钥交换，不能仅凭算法名字批量禁用。
  • IANA 的 D 标记和 RFC 发布只记录共同决策，不会改写进程配置。端点清单、正反向探针、失败归因、限期例外、回滚与漂移检测才构成已执行的证据链。

扫描结果没有变化，握手权力已经变化

一次例行扫描显示，某入口昨天和今天都支持 TLS 1.2。证书相同，端口相同，健康检查相同。若仪表盘只记录协议版本，运维团队很容易得出结论：本次加固没有改变兼容面。

真正变化的是服务器不再选择 TLS_RSA_*。

一台旧客户端于是连接失败。它并不是因为 TLS 1.2 被关闭，也不是因为服务器证书过期，而是因为双方不再拥有允许的共同密钥交换。这个失败落在 RFC 10015 的核心边界上。该文档于 2026 年 7 月以 IETF 标准轨 RFC 发布：在 TLS 或 DTLS 1.2 中，客户端不得提供、服务器不得选择 RSA 密钥交换套件。

这使“成功”和“失败”都不能脱离上下文。继续成功的 RSA 密钥交换不是值得庆祝的兼容；未被预先识别的客户端失败也不是良好治理。前者说明禁用没有落到运行路径，后者说明资产与依赖清单没有跟上安全决定。

一行 TLS 1.2 不能说明秘密如何产生

TLS 1.2 密码套件同时编码认证、密钥交换、对称加密与完整性选择。协议版本只是外壳。两条都显示“TLS 1.2”的连接，可以有完全不同的前向保密性、参数风险和密钥重用范围。

RFC 10015 对四类 DH 作了明确区分。FFDH 是有限域上的非临时 Diffie-Hellman，静态 DH 公钥存在认证证书中。FFDHE 在握手中发送临时公钥，再由证书认证。ECDH 与 ECDHE 在椭圆曲线上形成同样的静态/临时区别。

对 TLS/DTLS 1.2，规范强度不能混写：

  • 非临时 FFDH：客户端 MUST NOT 提供，服务器 MUST NOT 选择；
  • FFDHE：客户端 MUST NOT 提供，服务器 MUST NOT 选择；
  • RSA 密钥交换：客户端 MUST NOT 提供，服务器 MUST NOT 选择；
  • 非临时 ECDH：客户端 SHOULD NOT 提供，服务器 SHOULD NOT 选择。

文档还要求客户端不应使用、服务器不应接受 rsa_fixed_dh、dss_fixed_dh、rsa_fixed_ecdh 与 ecdsa_fixed_ecdh 四种固定 DH 证书类型。这些标识只适用于 1.2 及更早版本。

MUST NOT 与 SHOULD NOT 的差异直接决定例外流程。静态 ECDH 若暂时保留，需要清楚的特殊理由、范围与退出时间；但不能伪装成和 RSA 选择相同的绝对禁止。反过来，对 FFDHE 或 RSA，仅把套件排到优先级末尾并不合规。只要对端只提供旧套件时服务器仍能选择它，路径就没有退场。

两种字符串禁用会破坏规范边界

第一种错误是“禁用所有 RSA”。RSA 证书可以给 ECDHE 握手签名，密钥交换产生的秘密仍来自临时曲线密钥。这不是 RFC 10015 禁止的 RSA 密钥交换。按证书公钥名字一刀切，可能无谓中断大量合规路径。

第二种错误是“禁用所有 DHE”。RFC 10015 明确指出，TLS 与 DTLS 1.3 的 FFDHE 不承受文中列举的 1.2 机制问题，因此仍然可以提供。若配置工具没有把版本纳入判断，就会把针对旧构造的决定扩大为整个算法家族禁令。

所以最小证据单元不能是“证书为 RSA”，也不能是“服务支持 TLS 1.2”。它应当是：哪个终止点加载了哪份配置，客户端提供了什么，服务器选择了什么，最终以什么版本与套件完成或拒绝握手。

FFDHE 为何在 1.2 中失去保留资格

“临时”通常意味着过去会话不应因长期认证密钥泄露而解密，但它不是全部安全结论。TLS 1.2 的有限域组选择长期受到互操作压力。服务器可以给出自定义组；客户端在握手时几乎不可能完整验证任意组是否具有安全结构。一旦组不可信或不支持，旧机制也没有清晰的备用协商让客户端改选另一组。

RFC 7919 后来定义了可协商的标准 FFDHE 组，并记录了广泛兼容与组大小之间的历史压力。RFC 10015 汇总了退出 1.2 路径的理由：自定义组可能含小子群；1024 位组仍因兼容性被采用；攻击者可以把高成本预计算摊到使用同一常见组的大量流量上。

“套件名带 E”也不证明实现每次真正生成并销毁新秘密。密钥重用会重新打开 Raccoon 一类时序风险；非临时 FFDH 除非正确实现严格常数时间缓解，否则天生面临相近问题。RFC 作出的不是对 DH 的抽象否定，而是对 TLS 1.2 中参数选择、验证、兼容性与秘密生命周期组合的判断。

RSA 密钥交换把一次薄弱扩展为历史风险

TLS 1.2 的 RSA 密钥交换由客户端生成预主秘密，再使用服务器 RSA 公钥加密。它没有前向保密性。今天被保存的密文若在未来与私钥相遇，旧会话可能被回溯解密。

实现层还要面对 Bleichenbacher 型预言机。服务器若以可观察的时间、错误或网络行为区别处理畸形 RSA 密文，攻击者可以逐步恢复秘密。ROBOT、DROWN 等后续工作说明，完美实现反制并不容易，类似缺陷会反复出现。

影响还可能横向扩散。TLS/DTLS 1.2 缺少便利的密钥域隔离，多个端点常共享同一 RSA 私钥。最弱的一台旧设备若暴露预言机，可能改变其他端点历史流量的风险判断。因此，证书到期清单之外，还必须有私钥指纹与复用范围图。

注册表能描述决定，不能替进程执行

RFC 10015 更新了 17 份早期 RFC，包括 TLS 1.2、DTLS 1.2 与 BCP 195 的安全建议。IANA TLS 参数注册表 把相关密码套件和客户端证书类型的 Recommended 栏改为 D，并加入 RFC 10015 引用。RFC 9847 说明，D 表示不鼓励新实现或新部署使用。

这项注册能让开发者、采购方和运营者使用同一分类，也能支持默认值、扫描规则与验收测试。它不能触达一台正在运行的负载均衡器。

注册表与握手之间隔着 TLS 库、编译选项、密码提供器、应用框架、环境变量、代理、CDN、设备固件、区域模板与紧急覆盖。一份正确的代码仓库配置，可能被 sidecar 或控制台中的旧设置取代。源站完成清理，也可能被边缘终止点重新暴露。

因此，标准文本和配置变更只能证明意图。有效配置与真实握手才证明执行。

在切断路径之前建立协商账本

第一步不是改一条 cipher string，而是找到全部决策点：公网入口、内部 API、出站客户端、DTLS 服务、服务网格、CDN、代理、硬件设备与嵌入式客户端。每个对象都要记录负责人、TLS 库与密码提供器、实际加载的套件、版本边界、SNI/ALPN 规则、证书用途、私钥复用、区域与客户端群体。

第二步是采集行为基线。成功连接需要关联协议版本、密码套件、密钥交换和作出选择的终止层。失败需要记录第一个可行动原因：没有共同套件、组不支持、证书拒绝、版本不符，还是传输成功后的应用失败。

第三步是设计正反向 canary：

  • 只提供 TLS 1.2 RSA 或 FFDHE 的客户端应当失败；
  • 提供合规临时交换的 TLS 1.2 客户端应当成功；
  • TLS 1.3 应继续可用，其 FFDHE 路径不应被误伤；
  • 同时提供新旧套件时，服务器应选择预期的新路径，不能静默回落。

探针必须穿过每一层终止点。源站成功不能证明 CDN 边缘的选择，内部代理的结果也不能证明公网监听器。上线按真正的责任边界分片：一类 listener、一个区域、一个代理层或一批客户端，而不是全局同时切换。

每个切片保留前后配置指纹、握手样本、失败分布、应用 canary 与可限定范围的回滚包。“新配置已部署”只是事件；“禁止路径在观测中消失，同时受支持路径继续工作”才是结果。

运行代码决定事实落点

Heng Lu 的运行代码优先原则在这里具有直接可测性。RFC 可以定义约束，IANA 可以记录约束，审查流程可以批准约束；但它们都不能替生产端点生成一次握手 transcript。

他的最小初始规范、未来本地决策与自愿采用框架也说明，共同规则与本地权力并不矛盾。共同层可以把不再互操作的 1.2 组合写成确定性条件。运行端点的参与者保留清单、迁移次序、替代方式、隔离、回滚与例外决策，并对这些决策的后果负责。

本地权力不是把禁止套件重新命名为合规，而是让每一项兼容代价有明确主体、明确范围和可验证的结束条件。RFC 10015 划线；真正使那条线存在的是端点加载的配置与对端看到的行为。