TLS 密码套件协商：代理IP 链路上算法是怎么被谈出来的

代理IP 链路上的 TLS 握手里有一项常被忽略的”谈判”：客户端把支持的密码套件列表（每个套件是一组算法的打包，密钥交换 + 身份认证 + 对称加密 + MAC）放在 ClientHello 里发给服务端，服务端从列表里挑一个回 ServerHello。这一选，就决定了代理IP 链路上数据的加密强度、性能开销和兼容性——同一目标站，浏览器和代理设备支持的算法不同步，握手就会反复失败或被强制降级。

密码套件是什么。一段像 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 这样的字符串，拆开看：ECDHE 是临时椭圆曲线密钥交换（决定”前向保密”），RSA 是身份认证算法（决定”怎么证明服务端身份”），AES_256_GCM 是对称加密和分组模式（决定”数据怎么加密”），SHA384 是 MAC 算法（决定”完整性怎么验”）。每一个套件都是这一组四件套的打包，TLS 握手第一步就是在两端支持的套件列表里找交集。

为什么走代理IP 后差异被放大。代理链路把一条 TLS 连接拆成两段：本机到代理（通常代理客户端不解密，透传 TCP 流）、代理到目标站（独立建立 TLS）。本机到代理的链路只做”TCP 搬运”，不参与套件协商；但代理到目标站这一段，代理设备要代表自己发 ClientHello，目标站按代理设备的算法能力挑套件——如果代理只支持老旧套件（RC4、SHA1、3DES），即使浏览器支持 AES_256_GCM，链路也会被强制降级到弱算法。反过来如果目标站只支持老套件而代理已经禁用了，握手直接失败。中间设备或代理客户端）也可能在不解密的情况下掐掉弱套件的握手包，让协商从一开始就通不过。在代理IP 环境下这个问题更容易被放大。

怎么判断是套件在作怪。用 Wireshark 抓 ClientHello，看客户端列出的套件列表；再抓 ServerHello，看服务端挑了哪一个。如果两边对不上、最终选了一个意料之外的弱套件（如 TLS_RSA_WITH_AES_128_CBC_SHA），问题大概率在中间设备或代理出口的算法能力上。再用浏览器开发者工具的安全面板看”连接详情”里的”使用密码套件”字段，与目标站宣称的能力做对比，定位是客户端问题、代理问题还是服务端问题。

处置方向。第一，客户端升级到支持现代套件（ECDHE + AES-GCM + SHA-2 系列）的版本，老浏览器/老代理客户端是套件协商失败的常见源头；第二，代理设备选支持前向保密（ECDHE/ECDSA 系列）的服务商，避免链路只支持非 PFS 套件；第三，企业或合规环境如果禁用了部分套件，浏览器列表里要保留与目标站兼容的最低版本；第四，对实在谈不拢的旧站点，临时回退到 1.2 + 主流套件是务实的做法，不要硬扛 1.3 的零套件交集。

实际抓包怎么看

打开 Wireshark，过滤 tls.handshake.type == 1（ClientHello），看”Cipher Suites”字段——这是客户端愿意用的列表。然后过滤 tls.handshake.type == 2（ServerHello），看”Cipher Suite: “后面那个被选中的套件。如果选中的是老套件（如 TLS_RSA_WITH_AES_128_CBC_SHA），而客户端明明列出了 AES_256_GCM，问题就在中间设备——它把 AES_256_GCM 的扩展掐了或者只允许老套件通过。代理IP 链路上最常见的是：代理出口到目标站这一段算法能力有限，强制把整条链路拉到弱套件，加密强度和性能都跟着掉。

注意事项：密码套件协商是 TLS 握手的一环，与 TLS 版本协商（93/1814）、ALPN 协议协商（95）、SNI 域名指示（1656）、会话恢复（1853/2136）一起构成完整的握手流程——改一个套件，握手的轮次、扩展、证书验证都会跟着变，不要只盯密码套件一项来定位所有 TLS 故障。配合”使用 TLS 版本”和”使用协议”一起读，才能把”握手挂在哪一步”讲清楚。

密码套件不是孤立的算法，是密钥交换、身份认证、对称加密、完整性校验的四件套打包——代理IP 链路把 TLS 拆成两段，中间设备的算法能力往往比浏览器还旧，套件被强制降级是链路质量被低估的常见原因。