2016年，信息泄Sweet32漏洞公开那天，露漏我正维护着一套老旧的信息泄VPN网关。CVE-2016-2183，露漏CVSS评分7.5，信息泄影响DES和3DES的露漏64位块加密。攻击者只需要在网络上抓包，信息泄收集足够多的露漏密文，就能还原出明文片段。信息泄这不是露漏理论推演——研究团队用实际流量在30小时内攻破了3DES的加密会话。
DES的信息泄问题更直接。56位密钥长度，露漏1998年EFF用一台25万美元的信息泄机器在56小时内暴力破解。今天，露漏一块几百美元的信息泄FPGA板子几小时就能跑完整个密钥空间。3DES把DES跑了三遍，密钥长度名义上112位或168位，但中间相遇攻击把有效强度压到约112位。更糟的是，Sweet32利用的是块大小而非密钥长度——64位块意味着生日攻击在约2^32个块后就能触发碰撞。一条长连接传输几十GB数据，完全可能达到这个阈值。
谁还在用
金融行业的老核心系统、工业控制网络里的串口转以太网模块、某些医疗设备的HL7接口。我见过一台CT机的工作站，Windows XP SP3，TLS握手列表里只有DES-CBC3-SHA。厂商的补丁？没有。设备还在保修期内，但换协议意味着换整套影像系统，报价七位数。医院选择继续用，把设备隔离在独立VLAN里。
浏览器端的情况好一些。Chrome 50、Firefox 48之后默认禁用了3DES。但很多企业内网应用跑在Java 6或.NET 2.0上，默认加密套件里3DES排在前列。2019年我做一次内网评估，用sslscan扫了200台服务器，37台还在协商3DES。管理员说“业务系统太老，改不了”。
攻击怎么落地
Sweet32不需要中间人位置。攻击者在同一广播域或能镜像流量的地方就行。抓包，提取TLS记录层密文，等碰撞出现。碰撞意味着两个不同的明文块加密后产生相同密文块——通过XOR关系能推出明文。实际攻击中，研究者用JavaScript注入让受害者浏览器反复发送包含敏感信息的请求，配合网络抓包，还原出了会话Cookie。
DES的暴力破解更粗暴。用Hashcat配合GPU集群，DES的LM哈希每秒能跑几百亿次。如果拿到的是3DES的密文，攻击者会先尝试降级——很多实现允许协商回退到单DES，因为兼容性配置没关。
怎么处理
能换AES的全换。AES的128位块大小直接免疫Sweet32类攻击，密钥长度也足够。TLS配置里把3DES从 cipher suite 列表里删掉，别用“DEFAULT”或“HIGH”这种模糊标签。老系统如果实在动不了，限制单条连接传输的数据量——比如让HTTP连接每传1GB就强制重协商，但这只是缓解，不是修复。
OpenSSL 1.1.0之后默认把3DES归入“弱加密”，但很多发行版编译时没启用这个分类。检查你的 openssl ciphers -v 'ALL' 输出，看到 DES-CBC3-SHA 还在列表里，手动把它移到 !3DES 排除掉。Java应用改 java.security 文件，删掉 jdk.tls.legacyAlgorithms 里的3DES条目。
我自己的做法更极端：在边界防火墙上直接阻断所有ClientHello里包含3DES套件的TLS握手。会误伤一些老客户端，但那些客户端本来就不该再连生产环境。漏扫报告里再出现DES或3DES，直接标高危，不解释。
这漏洞不新，但清理速度比想象中慢。2023年Shodan上还能搜到几十万台开放443端口的设备只支持3DES。不是技术问题，是优先级问题——直到有人拿它做跳板进了内网，才会被排上日程。