2026年7月，互联网工程任务组（IETF）发布标准轨文件RFC 10015，在TLS 1.2和DTLS 1.2里给两种密钥交换判了重刑：有限域Diffie-Hellman（DH/DHE）和RSA密钥交换被标为MUST NOT——协议规范里最重的否决级别。静态ECDH套件也被点名，但只拿到SHOULD NOT，等于挨了警告没被封杀。这份文件同时改写了此前17份相关RFC，是TLS 1.2生命周期里少有的大规模清理。
容易读错的地方也在这里：这不是宣布RSA不安全了，而是宣布RSA用来直接给会话密钥加密的那种老办法，在TLS 1.2里已经没资格留任。
判死刑的是密钥交换方式，不是RSA本身
RFC 10015动的是"怎么协商会话密钥"这一层，跟"证书怎么签发、身份怎么认证"是两回事。被禁的TLS_RSA_WITH_AES_128_GCM_SHA256，用的是客户端拿服务器长期RSA公钥直接加密预主密钥的老式握手——密钥一旦被破，历史流量全部可回溯解密，没有前向保密。而TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256仍然合规，因为它只是用RSA签名做身份认证，真正的密钥协商走的是临时ECDHE。同一张RSA证书，装在两种套件里，命运完全不同。
同一批被点名的还有几个证书类型：rsa_fixed_dh、dss_fixed_dh、rsa_fixed_ecdh、ecdsa_fixed_ecdh，全部拿到SHOULD NOT——这些都是把DH/ECDH公钥直接焊进证书、每次握手都复用同一把密钥的老古董。
封杀的是密钥怎么协商，不是证书怎么签发
十年打不完的补丁
这次清理不是突然起意，背后是一串反复出现的攻击史。2015年的Logjam证明，攻击者只要对一个被广泛复用的1024位DH素数做一次昂贵的预计算，之后就能低成本破解所有用这个素数的连接——RFC正文提到，目前已知的离散对数破解纪录是795比特，而现实中不少运营商为了兼容旧客户端，DH分组还卡在1024比特左右，安全余量并不厚。
RSA这边的麻烦更缠人：Bleichenbacher攻击的变种以ROBOT、DROWN等名字反复重现，原因很朴素——相关的填充校验countermeasure实现起来太容易出错，几乎每隔几年就有新变种冒出来。加上（D）TLS 1.2没有密钥的域隔离机制，一台服务器出漏洞，所有共用同一把RSA长期密钥的站点都会被牵连。静态DH和静态ECDH则容易撞上Raccoon一类的侧信道——密钥被反复复用，攻击者靠计时差异就能反推出会话密钥。
TLS 1.3为何全身而退，谁会真的掉线
这份文件把范围明确限定在TLS 1.2和DTLS 1.2，因为TLS 1.3设计之初就没留这些坑：静态RSA密钥传输和静态ECDH被直接从协议里砍掉了，FFDHE分组虽然还能用，但走的是标准化协商，不存在TLS 1.2那种"客户端没法验证服务器自定义分组是否安全"的结构性缺陷。换句话说，同样是DH，在TLS 1.3里没事，在TLS 1.2里出局，问题从来不在算法本身，而在部署模型。
- 风险.真正会因此握手失败的，是那些跑着老版本Java、嵌入式设备、工业控制系统和私有中间件的系统——它们往往长期锁定在TLS_RSA_、TLS_DHE_一类套件上，运维排查的第一步就是逐条核对服务器和负载均衡器上还在用哪些套件。
静态ECDH只拿到SHOULD NOT而非MUST NOT，某种程度上也是IETF自己承认的让步——运营商通常没什么理由继续保留它，但规范留了余地，没有把话说死。这份文件本身不会立刻让互联网变天，接下来更值得盯的是IANA是否同步更新TLS参数注册表状态，以及OpenSSL、BoringSSL这类主流库什么时候把这些套件默认关掉——那才是真正影响握手成败的时间表。