几个月前处理一份安全扫描报告时有一行结果让我印象很深远程主机支持 RSA 密钥交换。旁边几个刚接触 HTTPS 的同事直接问HTTPS 里的 RSA 不就是用来加密的吗为什么扫描器还把它标成风险这个问题恰好踩中了很多人对 HTTPS RSA 握手最大的误解——RSA 在握手过程中不是“站在门口的一把大锁”它只是握手里一个可选的密钥协商方案选错了位置整条链路的安全属性会完全不同。所以这篇我想把 TLS 1.2 里最典型的 RSA 密钥交换握手从头到尾拆开为什么流程要设计成这个样子、每一条报文里到底藏了什么、怎么在自己电脑上用 OpenSSL 复现、以及安全扫描说“RSA 密钥交换危险”时到底该去改哪里。适合刚接触网络协议、正在排查 HTTPS 握手问题的开发也适合把 TLS 配置当黑盒的运维。读完之后你应该能自己抓包看明白 ClientHello 到 Finished 的全过程。1. 先分清层和顺序TLS 握手发生在 TCP 三次握手之后1.1 为什么要把 RSA 握手和 TCP 握手分开看网上聊 HTTPS永远绕不开“TCP 三次握手、四次挥手”这个话题很多面试题也会把这三样绑在一起。实际排查接口超时的时候Wireshark 里先看到的确实也是一堆 TCP SYN、SYN-ACK、ACK但紧接着出现的不是 HTTP 请求而是 TLS 的 ClientHello、ServerHello 这些握手消息。不少初学者在这里就乱了TCP 不是已经握手过了吗怎么又出来一次握手这里面的关键区别是TCP 握手发生在传输层确认的是“网络链路通不通、对方进程收不收包”而 TLS 握手跑在 TCP 连接之上它解决的是另外两个问题你面前这台服务器到底是不是它声称的那台服务器以及双方后面用什么密钥来加密数据。可以这样理解TCP 握手是两个人互相确认“我能听到你说话”TLS 握手则是确认“你的身份证真实有效”然后双方悄悄约定一套暗号。如果 TCP 字节流都没建立起来TLS 握手消息根本没地方传所以顺序必然是“TCP 三次握手 → TLS 四次握手 → HTTP 请求”。很多人会误把 TLS 握手的过程也叫作“三次握手”其实准确说法是四次 Flight也叫四次消息交换。每次 Flight 可以是单条消息也可以是多条消息打包在一起发送等会儿拆报文时会看得更清楚。1.2 TLS 握手真正要谈定的三件事TLS 握手比 TCP 握手复杂不是因为它想做复杂而是因为它需要同时完成三件互相关联的事协议版本协商双方必须统一用 TLS 1.2、TLS 1.3 还是更老的版本版本不一致时直接决定后面所有流程身份认证服务端要把自己的证书链交给客户端客户端去验证这个证书确实是可信 CA 签发且域名匹配密钥协商双方要生成一个只有自己和对方知道的对称密钥后续 HTTP 正文全部用这个对称密钥加密传输。如果只用对称加密客户端把密钥发给服务器这个过程没有任何保护中间人一抓包就能拿走。如果只靠非对称加密性能又不够跑完整条 HTTP 消息。所以 TLS 的现实方案是用非对称密码学解决身份验证和密钥传递再用协商出来的对称密钥加密后续真正传输的业务数据。RSA 握手就是“用 RSA 算法来传递对称密钥”这一种具体做法ECDHE 握手则是另一种做法。两个流派会在后文展开对比现在只要记住这个核心定位就够了。2. 被 RSA 绕进去之前先把非对称加密的两个用法分开2.1 公钥加密、私钥签名RSA 的两副面孔RSA 是个历史悠久的非对称算法但它本身有两副面孔使用场景完全不同。第一副面孔是公钥加密数据用公钥加密后只有对应私钥能解开所以你可以把公钥公开出去别人用它加密内容发给你。第二副面孔是私钥签名数据被私钥处理后私钥持有者无法抵赖因为任何持有公钥的人都能验证这段内容确实由该私钥签署过。这两副面孔在 HTTPS 握手里都会被用到但作用对象不一样。握手时服务端的证书里包含一个 RSA 公钥以及 CA 机构用自己私钥对这个证书做的签名。客户端验证证书时会顺着证书链往上找到根证书用根证书里的公钥先验证“这个服务器证书确实是由可信 CA 签发的”这是 RSA 的验签用法。等到后面要交换密钥时客户端又拿出服务端证书里的那个 RSA 公钥把一个随机生成的密钥种子加密后发给服务器只有持有对应私钥的服务器才能解开这又是 RSA 的公钥加密用法。如果不把这两副面孔分开很容易出现一个经典误区当安全报告说“RSA 密钥交换不安全”时有人误以为要禁用 RSA 证书甚至把服务器证书整个换掉。实际上报告针对的是密钥交换的那一种用法而不是证书签名。一个证书用 RSA 算法做签名完全没问题完全可以配合 ECDHE 密钥交换使用这也是现代网站最常见的组合之一。2.2 为什么不能用 RSA 直接加密整条 HTTP 正文既然服务端有 RSA 公钥客户端为什么不直接把 HTTP 请求用公钥加密发给服务器这个问题的答案分三层。第一性能差距非常大。RSA-2048 的加解密运算量远高于 AES-128 这类对称算法把整条 HTTP 正文逐块做 RSA 加密CPU 开销会让人无法接受。二来加密后有长度膨胀问题RSA 每加密一个块还会附带填充大量请求体根本无法高效处理。第二RSA 只能加密非常小的数据。以 RSA-2048 为例一次能加密的明文上限大约 245 字节远超这个长度的数据都需要分块处理而这会引入更多的填充和性能问题。密钥种子的长度为 48 字节正好可以一次加密完成这是设计上的精妙之处。第三也是最容易被忽略的用 RSA 公钥加密传输的每个请求服务端都能用私钥解开也就是“能解开所有历史流量”。一旦私钥泄露过去的加密请求全部会被还原。这也是后来 ECDHE 被主流配置采用的核心原因它的设计目标是让每个会话使用临时密钥即使长期私钥泄露历史流量也无法被批量解密。这个特性叫前向保密后文专门展开。既然直接用 RSA 加密正文不可行握手的思路就是客户端生成一小段随机数据Pre-Master Secret用服务端公钥加密传过去双方利用这段随机数据各自派生出真正要用的对称会话密钥。RSA 只是在握手阶段扮演了一次“密钥保险箱”的角色正式业务数据还是交给对称加密。2.3 RSA 密钥交换和 ECDHE 密钥交换的本质区别这两者的区别不在“RSA 算法本身安不安全”而在服务器私钥在整个生命周期里的参与程度。RSA 密钥交换时客户端每次生成的 Pre-Master Secret 都用同一个服务器 RSA 公钥加密。如果攻击者保存了历史上所有的握手流量某一天拿到了服务器私钥那么他可以回头把每条握手里的 Pre-Master Secret 全部解开再用推导规则还原每条会话的对称密钥历史流量整体沦陷。ECDHE 则不同服务器在每次握手时都会临时生成一对 DH 私钥和公钥再用自己的长期 RSA或 ECDSA私钥给这个临时公钥签名。客户端收到后验证签名认为临时公钥确实来自服务器然后双方通过 DH 算法计算出一个共同的会话密钥。服务器长期私钥全程没有直接参与加密会话密钥只用来给临时公钥做认证。就算攻击者以后拿到了长期私钥因为握手时的临时 DH 私钥已经销毁旧流量也无法被还原。这里有个重要的观察RSA 在 ECDHE 握手里依然存在但角色从“密钥加密者”变成了“签名的验证基础”。所以“禁止 RSA”和“禁止 RSA key exchange”是两个完全不同等级的操作禁用错了现代 ECDHE suite 也会因为无法完成签名而不可用。3. TLS 1.2 RSA 握手四次飞行逐包拆解3.1 第一次飞行ClientHello 在列表上秀出所有密码套件整个握手从客户端发送 ClientHello 开始。客户端在 TCP 连接建立后向服务器声明自己支持的 TLS 版本、支持的 Cipher Suite 列表、一个 32 字节的客户端随机数以及可选的 Session ID、SNI 等扩展。客户端随机数不是可选的装饰品它会被后续的密钥派生过程拿去做输入参数。如果每次握手都用相同随机数重放攻击就会变得非常容易。Cipher Suite 列表则决定服务器可以从哪些算法组合里挑一个。列表里的一串名字比如 TLS_RSA_WITH_AES_128_GCM_SHA256拆开看就是密钥交换算法RSA证书签名算法RSA对称加密算法AES-128-GCM消息认证/哈希算法SHA-256很多文章只说“HTTPS 用 RSA”其实 RSA 可能只代表密钥交换或签名环节AES 才是真正加密 HTTP 正文的算法。看到这里应该明白了RSA 只是整个套件里的一个环节。3.2 第二次飞行服务端挑完算法立刻把身份证递出来服务器收到 ClientHello 后会从客户端列出的 Cipher Suite 里选出自己支持且优先级最高的一组。如果它发现客户端列出了 TLS_RSA_WITH_AES_128_GCM_SHA256而服务器也愿意支持就会在 ServerHello 消息里把最终的套件名返回。紧接着服务器会发送 Certificate 消息。消息里通常是证书链按顺序包含服务器证书和中级 CA 证书。现代服务器为了减小体积可能不发送根证书因为客户端本地已经信任了根证书。客户端拿到证书链后会一级一级向上验证签名最后查到自己信任的根证书才放心。这一步最容易被忽略的是“证书和域名匹配”的校验即使证书链可信如果证书 Common Name 或 Subject Alternative Name 和当前访问域名对不上浏览器依然会报错。这个校验虽然没有单独的握手消息但会在客户端内部完成一旦失败握手立刻终止。服务器发完证书后对它来说已经完成了自己这边的信息传递随后会发送 ServerHelloDone表示“我能给的信息给完了现在轮到你了”。注意在 RSA 密钥交换流程里没有 ServerKeyExchange 消息这也是 RSA 握手的特征之一后面会用到这个特征来做判断。3.3 第三次飞行RSA 最关键的一步ClientKeyExchange客户端验证完证书后会生成一串 48 字节的 Pre-Master Secret。前两字节通常是 TLS 版本号后面 46 字节是安全随机数。这个随机数的质量很重要如果随机性不够强后续派生的密钥就可能被预测。然后客户端把这个 48 字节的 Pre-Master Secret 用服务器证书里的 RSA 公钥加密放进 ClientKeyExchange 消息发送。RSA-2048 加密后密文正好是 256 字节。服务器用自己的 RSA 私钥解出来到这里双方手里都有了一模一样的 Pre-Master Secret。之后双方各自通过 PRF伪随机函数派生出 Master Secretmaster_secret PRF(pre_master_secret, master secret, ClientHello.random ServerHello.random)紧接着再由 Master Secret 扩展出通信需要的对称密钥块key_block PRF(master_secret, key expansion, ServerHello.random ClientHello.random)注意第二个公式里随机数顺序变成了“服务器随机数 客户端随机数”这是 TLS 规范里的细节目的是让握手中双方计算的输入不完全相同防止方向混淆。从 key_block 里会切分出客户端加密密钥、服务端加密密钥、客户端 MAC 密钥、服务端 MAC 密钥等。两边各自派生但结果必须一致这是后续 Finished 校验的基础。3.4 第四次飞行双方同时宣告开始加密客户端发出 ClientKeyExchange 后紧接着会发送 ChangeCipherSpec 消息表示“从下一条消息开始我发出的内容会走加密通道了”。然后客户端发送 Finished 消息内容是之前所有握手消息的哈希结果经过 PRF 运算后的 12 字节 verify_data。因为 Finished 本身已经使用协商出来的密钥加密服务器如果能成功解密并校验里面的 verify_data就证明密钥派生完全正确且之前的握手消息没有被中间人篡改。服务器确认客户端的 Finished 没问题后同样会发送自己的 ChangeCipherSpec 和 Finished。客户端收到后做相同校验校验成功握手正式完成可以开始传输 HTTP 请求了。完整流程可以用下面的文本时序图还原客户端 服务端 |--- ClientHello -------------------------------| |-- ServerHello --------------------------------| |-- Certificate --------------------------------| |-- ServerHelloDone ----------------------------| |--- ClientKeyExchange(RSA加密Pre-Master) ------| |--- ChangeCipherSpec --------------------------| |--- Finished(加密) ----------------------------| |-- ChangeCipherSpec ---------------------------| |-- Finished(加密) -----------------------------| | 应用数据加密传输 |这里有个经常被忽略的点ChangeCipherSpec 并不是握手消息而是单独的 TLS 记录类型。它出现的位置在 ClientKeyExchange 之后、Finished 之前表示密钥切换时机的边界。如果你在抓包里看到 ClientKeyExchange、ChangeCipherSpec、Finished 连续出现说明这次就是一次密钥协商完成的标准流程。4. 动手实测OpenSSL 一跑状态机立刻现原形4.1 为什么推荐用本地 OpenSSL 而不是直接抓公网站点对着公网 HTTPS 网站抓包当然也能看到握手但今天大部分网站和服务端已经默认优先支持 ECDHE服务器的 ClientHello 列表里可能把 TLS_RSA 系列排得非常靠后甚至干脆不支持。想稳定观察 RSA key exchange 的完整流程本地起一个服务最靠谱第一能强制指定 Cipher Suite第二不会因为频繁握手给业务系统造成压力第三还可以随意打断重来。另外直接抓网上真实站点也可能涉及到隐私和安全边界自己本地搭建测试环境所有报文都归自己所有是最稳妥的做法。4.2 一分钟搭一个只支持 RSA 密钥交换的本地服务先准备一张自签名证书。这里讲清楚TLS 握手协议本身不关心证书是不是由权威 CA 签发只要客户端信任就可以走完流程。本地测试用 OpenSSL 自签一张即可openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 730 -nodes参数里的 2048 是 RSA 密钥长度-nodes表示私钥不加密测试环境可以这样简化。生成后在同一目录启动服务端openssl s_server -accept 4433 -cert cert.pem -key key.pem -tls1_2 -cipher AES128-SHA -state -msg这里-tls1_2把协议卡在 TLS 1.2-cipher AES128-SHA强制使用 TLS_RSA_WITH_AES_128_CBC_SHA 这个 Cipher Suite它前面的 Kx 就是 RSA即密钥交换算法为 RSA证书签名算法 Au 也是 RSA。-state会把握手状态实时打出来-msg会打印每条消息的十六进制内容适合做对照实验。再开一个终端用客户端发起连接openssl s_client -connect 127.0.0.1:4433 -tls1_2 -cipher AES128-SHA -state -msg握手成功后s_client 会进入交互模式你甚至能手工输入GET / HTTP/1.1之类的内容看服务器怎么响应。如果完整走通服务端会打印类似下面的状态序列SSL_accept:before SSL initialization SSL_accept:SSLv3/TLS write server hello SSL_accept:SSLv3/TLS write certificate SSL_accept:SSLv3/TLS write server hello done SSL_accept:SSLv3/TLS read client key exchange SSL_accept:SSLv3/TLS read change cipher spec SSL_accept:SSLv3/TLS read finished SSL_accept:SSLv3/TLS write change cipher spec SSL_accept:SSLv3/TLS write finished看到这些状态基本就能和前面讲的四次 Flight 一一对应上了。建议你把-cipher换成ECDHE-RSA-AES128-GCM-SHA256再跑一遍对比状态序列的变化。你会看到服务端多了一条write server key exchange而 RSA key exchange 流程里没有这条消息这是两种方案最直观的区别。4.3 在 Wireshark 里定位要看的几个字段OpenSSL 命令行已经足够看出握手成功与否但如果你想盯着字段理解每一条消息Wireshark 还是最直观。启动抓包过滤 TCP 端口 4433重新发起握手然后跟随 TCP 流。重点查看这几处ClientHello 里的 Cipher Suites 列表可以看到客户端列出的套件五花八门其中 TLS_RSA_WITH_AES_128_CBC_SHA 或类似 RSA Kx 开头的项就是允许 RSA 密钥交换的证据。ServerHello 里的 Cipher Suite 字段服务器最终挑选的是哪一种如果强制指定成功这里一定是 TLS_RSA 开头。Certificate 消息证书在第几个包出现、证书链长什么样都能在报文树里展开。ClientKeyExchange 消息展开后能看到 Encrypted Pre-Master Secret密文长度应为 256 字节RSA-2048。这一步是整个 RSA 握手最容易定位的特征。Finished 消息此时无法再直接查看明文内容因为消息已经被协商出来的对称密钥加密。用 Wireshark 过滤器可以快速定位tls.handshake.type 1 || tls.handshake.type 2 || tls.handshake.type 11 || tls.handshake.type 16 || tls.handshake.type 20类型 1 是 ClientHello2 是 ServerHello11 是 Certificate16 是 ClientKeyExchange20 是 Finished。过滤器只是辅助真正重要的是理解每个握手消息顺序背后的意义。4.4 SSLKEYLOGFILE 能让你看到“解密后的握手”但别滥用Wireshark 默认只能看到 TLS 握手头部Finished 之后的内容全是密文。如果只是做协议调试可以设置 SSLKEYLOGFILE 环境变量让 OpenSSL 或浏览器把本次握手的密钥种子写到文件里Wireshark 读到后能解开后续密文。export SSLKEYLOGFILE/tmp/tls_key.log curl --cacert cert.pem --tlsv1.2 --ciphers AES128-SHA https://127.0.0.1:4433/不过要注意这个日志文件实际等价于把会话密钥暴露给抓包工具只允许在自建测试环境或自己控制的调试环境里使用绝对不能在生产环境开更不能泄露给第三人。理解数据的保密边界比学会怎么抓包更重要。5. 被安全扫描标成风险之后RSA 密钥交换的真实问题与修法5.1 扫描器为什么能下这个结论安全扫描器报告“远程主机支持 RSA 密钥交换”时其实是在说这台服务器在握手时可能选择 TLS_RSA 这类使用 RSA 作为密钥交换算法的 Cipher Suite。扫描器做的事和普通 TLS 客户端很像发送一个 ClientHello服务器回一个 ServerHello扫描器发现 ServerHello 里选择了 RSA key exchange或者在服务器支持的套件列表里看到 RSA Kx 的项目就会标记出来。如果你访问的是国内或海外的某些 HTTPS 服务打开浏览器开发者工具的 Security 面板发现 ServerHello 选择的加密套件是 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256就不会被这则警告命中。这类问题的根源不是 RSA 算法本身被破解而是“用长期私钥直接参与密钥交换”的密码学设计不再符合现代安全要求。5.2 无前向保密为什么致命很多人对“前向保密”这四个字没有体感这里给一个实际场景。攻击者从某年一月开始持续记录你网站的加密流量虽然没有私钥解不开但他不着急只是默默囤着。半年后网站被拖库服务器 RSA 私钥泄露攻击者拿私钥回到自己硬盘上打开之前囤积的 ClientKeyExchange 记录把每条记录的 Pre-Master Secret 全部解开再结合握手随机数推出每条会话的对称密钥。结果就是过去半年的全部加密流量加密等于纹丝不动。ECDHE 能防住的核心点是每次握手临时产生的 DH 私钥在握手结束后立即销毁。攻击者囤流量囤得再多拿到的也只是服务器长期私钥对临时公钥做过的签名无法还原出已经被销毁的 DH 私钥自然算不出历史会话的对称密钥。对在线业务来说在关键时刻能保证“已经被攻击者拿到的加密文件无法被批量解密”就是前向保密最大的价值。这里需要强调边界服务器的长期私钥泄露后攻击者如果仍然在线是可以伪装成服务器重新发起握手的所以私钥泄露本身始终是严重事故。前向保密解决的是“历史流量被批量回溯”的问题不解决正在发生的中间人攻击。5.3 修改配置时别把 RSA 的“签名”和“密钥交换”一起关掉运维同学收到漏洞报告后第一个动作往往是去 Nginx 或 Apache 里调 Cipher Suite。这里最容易犯的错是看到“RSA”就把它全禁用结果配置一上服务直接启动失败或者握手全部报错因为服务器证书本身就是 RSA 签名的把签名算法对应的套件删干净之后整个证书体系就无路可走。推荐的做法是保留 ECDHE 系列套件显式排除 RSA key exchange 套件。Nginx 里可以这样写ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS:!RSA;注意字符串末尾的!RSA在 OpenSSL cipher 语法里它表示禁止 Kx密钥交换算法为 RSA 的套件并不会禁用 RSA 证书签名。所以 ECDHE-RSA-AES128-GCM-SHA256 依然保留因为它的密钥交换算法是 ECDHERSA 只负责服务器临时公钥的签名认证。改完之后可以用下面的命令自测如果服务器已经彻底不接受 RSA key exchange这条握手会失败openssl s_client -connect your-server.example:443 -tls1_2 -cipher AES128-SHA /dev/null反之如果你发现失败而 ECDHE 系列握手正常说明配置已经生效。把扫描报告里的“RSA key exchange”从风险列表里清掉但证书签名链路依然健在。5.4 为什么 TLS 1.3 直接不给你 RSA key exchange 选项TLS 1.3 对握手流程做了大幅精简最明显的一点是移除了 RSA 密钥交换也移除了 CBC 类加密套件、静态 DH、静态 ECDH 等一堆只提供“加密但不提供前向保密”的组合。TLS 1.3 留下的密钥交换模式基本只有 ECDHE 和 DHE服务器证书里的 RSA 公钥只用来验证签名不再用于加密 Pre-Master Secret。这也是为什么很多老系统升级到 TLS 1.3 之后安全扫描的风险项会瞬间减少。本质上不是 RSA 算法被淘汰而是密码学社区用实践达成了一个共识长期私钥不应该直接介入每一次会话的密钥生成过程。如果你维护的客户端还停留在 TLS 1.0/1.1无法支持 ECDHE那么 RSA key exchange 可能是保兼容的最后选择。但这类系统必须控制好范围只在封闭网络内或者在终端设备全面升级前临时使用并且要配合访问控制绝不能直接暴露在公网。5.5 给老环境的一条渐进式迁移路线如果你的服务器目前仍然承担着大量老客户端的兼容任务不能一夜间彻底禁用 RSA key exchange可以参考下面这种渐进式方案。先观察日志统计当前实际协商到 RSA key exchange 的会话数量。Nginx 的$ssl_ciphers变量可以记录每次握手最终协商的密码套件放到 access log 里跑一两周基本就知道哪些客户端真的还在依赖 RSA key exchange。接着按风险排序处理先开发环境关闭 RSA key exchange跑完回归测试看有没有客户端报错再灰度到预发环境最后才上生产。如果确有老客户端无法升级可以给它们单独划分端口或 VIP在独立区域保留最低限度配置入口处再配白名单限制来源。我在实际调服务器时有个习惯拿到任何所谓“安全配置模板”后不会直接复制粘贴而是先跑openssl ciphers -v 模板里的所有字符串看展开结果确认每一条套件的 Kx、Au、Enc、Mac 分别是什么。很多配置事故说到底就是没先看清楚“签名 RSA”和“密钥交换 RSA”的区别一杆子全打死了。最后分享一个小技巧查完配置后一定用openssl s_client -connect 域名:443 -tls1_2看一次 ServerHello 返回的真实 Cipher Suite浏览器和配置里的默认值不一定一致只有抓包看到的那一行才代表用户真正享受到的安全级别。
