HTTP/1.1：是时候说再见了
过去六年里，我们一直试图修补一个根深蒂固的漏洞，但现在是时候承认：HTTP/1.1 存在一个致命的、高危的缺陷，我们无法从根本上解决它。它必须被淘汰，否则我们的网络将持续面临威胁。
致命的缺陷：请求边界的模糊性
HTTP/1.1 的根本问题在于，它对 HTTP 请求边界的定义非常脆弱 。请求在底层的 TCP/TLS 套接字上简单地串联在一起，中间没有明确的分隔符，而且存在多种方法来指定请求的长度 。这就给攻击者留下了巨大的空间，可以制造歧义，让前端和后端服务器对一个请求在哪里结束、下一个请求在哪里开始产生不同的理解 。
当网站使用反向代理时（这在现代网络中非常常见），来自不同用户的请求会被汇集到共享的连接池中，然后发送到后端服务器 。如果攻击者能利用服务器链中的微小解析差异，就可能引发“desync”（不同步）攻击，将恶意的前缀附加到其他用户的请求上，从而导致整个网站被劫持 。
“看似安全”的假象
自 2019 年首次发现这一威胁以来，许多人认为通过更严格的解析和使用 HTTP/2 协议，我们已经解决了这个问题 。然而，这只是一个假象 。许多服务器和 CDN 供应商虽然号称支持 HTTP/2，但实际上在将请求转发给后端系统时，会将 HTTP/2 请求降级为 HTTP/1.1 。这种降级不仅失去了 HTTP/2 的安全优势，甚至比全程使用 HTTP/1.1 更危险，因为它引入了第四种指定消息长度的方式 。
传统的攻击方法和工具包现在往往会失败 。这是因为 Web 应用程序防火墙（WAF）会使用正则表达式来检测和阻止带有混淆
Transfer-Encoding 标头的请求 ，或者某些特定的检测工具在某些目标上无法工作 。这造成了一种“安全”的错觉，但只要做出最微小的改动，这种防御就会失效 。
Desync 攻击的演变：永无止境的对抗
每次我们认为自己已经完全理解了 Desync 威胁时，总会有新的攻击方式出现 。以下是 HTTP 请求走私（Request Smuggling）攻击的主要发展历程：
2004 年： 首次提出 HTTP 请求走私 。
2019 年： 重新发现并利用标头解析差异（CL.TE, TE.CL）。
2021 年： 利用 HTTP/2 降级（H2.CL, H2.TE）。
2022 年： 利用忽略 Content-Length 的端点（CL.0, H2.0, CSD）。
2024 年： 利用 dechunking 机制（TE.0）。
2025 年： 利用分块扩展（TE.TE）和 0.CL desync 攻击 。
最新的研究表明，即使是被普遍认为“无法利用”的
0.CL desync 攻击，也可以通过找到“早期响应”机制来绕过。攻击者甚至可以利用
Expect 标头 ，这个本是用于优化的古老特性，它本身的复杂性使得服务器和反向代理极易出错，从而导致新的 desync 漏洞 。
如何防御？淘汰 HTTP/1.1！
尽管所有这些攻击都是利用实现中的缺陷，但根本原因在于 HTTP/1.1 本身的协议设计 。它充满了各种“地雷”，如三种不同的长度指定方式、
Expect 和 Connection 这样的复杂标头以及 HEAD 等特殊情况 。这些因素相互作用，导致即使是微小的实现漏洞也可能带来严重的安全后果 。
六年的时间已经证明，我们无法通过修补单个实现来消除这一威胁 。我们过于害怕破坏对遗留客户端的兼容性，以至于无法应用真正的、健壮的验证或标准化措施 28。相反，我们依赖于容易被绕过的正则表达式防御 。
唯一的长期解决方案是采用上游 HTTP/2 。HTTP/2 是一个二进制协议，对每个消息的长度都有明确的定义，从根本上消除了歧义 。
对于网站管理员：
1.启用上游 HTTP/2： 确保您的代理（如 HAProxy、F5 Big-IP、Google Cloud）将请求以 HTTP/2 格式发送给您的后端服务器 。
2.敦促供应商改进： 如果您的供应商（如 Nginx、Akamai、CloudFront）尚未支持上游 HTTP/2，请提交工单并询问他们的计划 。
3.临时措施： 如果无法立即迁移，请在前端服务器上启用所有可用的规范化和验证选项，避免使用小众的 Web 服务器，并考虑禁用上游连接重用 。
HTTP/1.1 带来的技术债务已经成为我们安全态势中的一个巨大风险 。是时候集体行动，向世界展示 HTTP/1.1 是多么不安全了 。只有这样，我们才能最终“杀死”这个协议，建设一个更安全的网络 。
参考链接：
