工作来源
CODASPY 2024
工作背景
为保证兼容性，有时候客户端遇到连接错误时会主动尝试用更低版本的 TLS 协议进行重新协商。这就有了中间人攻击的空间，攻击者阻断高版本 TLS 握手，诱使客户端主动降级。浏览器应对降级攻击的研究很多，但企业常用的远程桌面软件、电子邮件软件、VPN 软件等各种软件，能否经得住考验？
传统握手过程不再赘述，TLS 1.3 进行了部分修改。降级攻击的典型流程，如下所示：
防御 TLS 降级的两个方式：Fallback SCSV 与 TLS 1.3 Sentinel Value，这里不再赘述，感兴趣的读者自行搜索。
工作设计
第一阶段：中间人首先中断客户端的首次 TLS 连接。如果客户端用一个更低版本的 TLS 协议重试，就说明它会降级。同时，检查这次重试有没有携带 Fallback SCSV。
第二阶段：如果客户端会降级，中间人则在模拟的服务器回应中，手动注入 Sentinel Value。如果客户端能正确识别并发送 illegal_parameter 警报，则认为它具备降级保护。
第三阶段：对于松耦合（可连接任意服务器）的客户端，让它连接到一个可控的、确定会发送 Sentinel Value 的服务器上，来最终确认客户端是否真的不做检查。
第四阶段：对于紧耦合（只连接自家服务器）的客户端，反过来测试它所连接的那个特定服务器，看服务器端是否会检查客户端发来的 Fallback SCSV 信号。
工作准备
37 个远程桌面程序、49 个电子邮件程序与 131 个 VPN 程序，具体列表如下所示：
工作评估
217 个应用程序中，有 42 个会被降级影响，大部分应用程序还是从根本上杜绝了降级攻击的发生。在这 42 个应用程序中，4 个应用程序既不发送 Fallback SCSV，也不检查 Sentinel Value，无论它们连接到哪个服务器，都容易受到降级攻击。也有 4 个应用程序，客户端缺乏防御，连接的特定的服务器又恰好缺少另一种防御。
工作思考
超过 90% 的跨平台应用，在不同操作系统上的 TLS 行为不一致 。例如，Array Motion Pro 这款 VPN，其 iOS 版有 SCSV 保护，Android 版干脆不降级，而 Windows 和 macOS 版则存在通用漏洞 。这种不一致性可能给企业的安全策略部署带来了巨大的混乱和风险 。
PS：深信服和天融信的 VPN 程序，是不是需要做个升级？
声明：本文来自威胁棱镜，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。
