Google Cloud 本周發布博客介紹最近一段時間新出現的谷歌規模攻擊類型：HTTP/2 快速重置。

攻擊者利用這個方法從 8 月份開始對谷歌云平臺的緩解客戶發起攻擊，其中攻擊者在某次攻擊中在 1 秒內發出了高達 3.98 億個請求，史上這也是擊攻擊目前有記錄以來的每秒請求數最高的一次攻擊。

HTTP/2 的利用藍點特性：

HTTP/2 的主要設計目標就是效率，其特性之一就是每秒提高 TCP 連接的利用率，與 HTTP/1.1 中的發出每個請求都是排隊處理不同，HTTP/2 中可以在單個 TCP 連接中打開多個并發流，請求每個流對應著一個 HTTP 請求。谷歌規模

理論上說并發打開流的緩解最大數量應該由目標服務器控制，但實際上客戶端的史上每個請求可以打開 100 個流，服務器也會處理這 100 個流，擊攻擊因為服務器并不能單方面調整限制。利用藍點

這種并發操作的每秒好處在于每個連接的利用率都可以提高 100 倍，這比 HTTP/1.1 的發出排隊處理要優秀的多。

HTTP/2 快速重置漏洞：

這個問題目前已經被標記為安全問題，編號為 CVE-2023-44487，嚴格來說這并不是安全問題，而是 HTTP/2 的特性被攻擊者利用，但谷歌覺得有必要引起業界關注，所以也提交了漏洞通報。

HTTP/2 還有個特點是 RST_STREAM，該協議允許客戶端向服務器發送 RST_STREAM 幀來取消先前的流，而且這還不需要客戶端和服務器進行任何協商，客戶端可以單方面這么干。

當服務器收到 RST_STREAM 幀時，在處理來自該 TCP 鏈接的任何其他數據之前，取消都將立即生效。

HTTP/1.1 攻擊、常規 HTTP/2 攻擊和 HTTP/2 快速重置攻擊的請求示意圖

攻擊者怎么操作的呢？攻擊者利用這個特性，在發出請求幀后立即發送 RST_STREAM 幀，這樣一個發起攻擊的客戶端開始工作后再快速重置請求，請求被取消后，HTTP/2 的連接實際還保持著打開狀態。

這樣就可以瘋狂發起請求然后再發送 RST_STREAM 幀，攻擊者不會發起超過并發流的限制，也就是 100，在 100 個并發流范圍內使用大量攻擊客戶端在每秒內發出多個請求(注意：在 1 秒內可以發出多次請求，100 并發流是單次請求中的上限，但每秒發出多次請求就可以快速放大攻擊。)。

這類攻擊導致請求的數量不再取決于 RTT 即往返時間，而是取決于服務器的可用網絡帶寬。

在典型的 HTTP/2 服務器實現中，服務器仍然需要為取消請求執行大量工作，例如分配新的流數據結構、解析查詢并進行標頭壓縮以及將 URL 映射到資源。

對于反向代理實現，可以在處理 RST_STREAM 幀之前將請求代理到后端服務器。

另一方面，發起攻擊的一方無需支付發送請求的費用，這對網絡帶寬的占用也不大，還可以放大攻擊規模，成本極低。

HTTPS/3 沒這個問題：

由于協議的差異，谷歌認為 HTTP/2 DDoS 不會被直接轉換為 HTTP/3 或 QUIC DDoS，谷歌目前并未看到有關 HTTP/3 DDoS 的大規模攻擊向量，盡管如此谷歌仍然建議 HTTP/3 服務器主動實施機制來限制單個傳輸連接完成的工作量。操作方法類似于 HTTP/2 DDoS 的緩解方案。

緩解方案見這里：https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack