來自新加坡國立大學、福州大學、謝菲爾德大學及約翰霍普金斯大學的研究人員近期揭露了一種名為 CDN Tsunami 的新型拒絕服務攻擊（DoS）。該攻擊的核心在於利用大型內容傳遞網路（CDN）在處理 HTTP/3 流量時的協議轉換機制，將低頻寬的請求放大，對後端來源伺服器（Origin Server）造成極高壓力的流量衝擊。研究顯示，在特定條件下，這種放大倍數最高可達 350 倍。
背景與協議失配問題
CDN 的主要功能是將快取內容推送到網路邊緣，以減少延遲並減輕來源伺服器的負擔。現代 CDN 通常在邊緣節點支持最新的 HTTP/3 協議，以提供更快的連線速度。然而，由於許多後端來源伺服器仍僅支持較舊的 HTTP/1.1 協議，CDN 必須在中間扮演翻譯者的角色，將接收到的 HTTP/3 請求轉換為 HTTP/1.1 請求再轉發給來源伺服器。
研究團隊指出，這種端到端協議的不一致（Mismatch）創造了一個安全漏洞。由於 HTTP/3 與 HTTP/1.1 在資料傳輸與標頭壓縮的運作方式截然不同，攻擊者可以利用這種轉換過程中的差異，以極小的成本觸發巨大的後端資源消耗。
核心攻擊技術：HBA 與 HCA
CDN Tsunami 攻擊分為兩種主要的技術路徑：HTTP/3 頻寬放大（HBA）與 HTTP/3 連線放大（HCA）。
HBA 攻擊利用了 HTTP/3 引入的 QPACK 標頭壓縮格式。QPACK 允許使用動態表（Dynamic Table）來儲存重複出現的標頭資訊，使得後續請求只需傳送一個短小的索引值（Index），即可代表一段較長的標頭內容。當 CDN 接收到這些短小的索引值時，必須將其解壓縮回完整的原始標頭，才能以 HTTP/1.1 格式轉發給來源伺服器。
攻擊者首先傳送一個包含巨大標頭的請求，讓 CDN 將其存入動態表，隨後不斷發送僅含索引值的微小請求。這導致攻擊者僅需極低的發送頻寬（部分測試低於 500 Kbps），就能讓來源伺服器接收到超過 100 Mbps 的解壓縮流量。在支持動態表的 Alibaba、Baidu 和 Tencent CDN 上，這種放大效果最為顯著。
HCA 攻擊則針對連線容量而非頻寬。HTTP/3 支持多路複用（Multiplexing），允許在單一連線中同時開啟多個串流（Streams）。研究發現，五家受測 CDN 在收到 HTTP/3 的標頭框架（HEADERS frame）後，會立即與來源伺服器建立 HTTP/1.1 TCP 連線，而不需要等待請求主體（DATA frames）到達。
攻擊者可以利用此特性，在單一 HTTP/3 連線中開啟大量串流，迫使 CDN 與來源伺服器建立大量後端 TCP 連線。接著，攻擊者以極慢的速度傳送資料，使這些連線保持開啟狀態而不被超時關閉，迅速耗盡來源伺服器的最大連線數，導致合法用戶無法訪問，出現 504 Gateway Timeout 或 503 Service Unavailable 等錯誤。
受影響範圍與實務影響
研究團隊對包括 Cloudflare、Amazon CloudFront、Fastly、Alibaba、Baidu 和 Tencent 在內的六大 CDN 供應商進行了測試。結果顯示，所有供應商都對 HBA 頻寬放大攻擊敏感，而除 Cloudflare 之外的五家則對 HCA 連線放大攻擊敏感。Cloudflare 能免疫 HCA 攻擊，是因為其機制會緩衝完整的請求後才開啟後端連線。
在頻寬放大倍數方面，支持動態表的 Alibaba、Baidu 和 Tencent 表現最高，最高可達 350 倍（靜態表放大則在 54x 至 66x 之間）。而 CloudFront、Cloudflare 和 Fastly 的放大倍數則落在 36.41x 至 51.2x 之間。
為了評估真實風險，研究人員對 Tranco Top 1M 列表中的子域名進行掃描，發現約有 42,330 個子域名部署在這些 CDN 上且開啟了 HTTP/3，具有潛在的受攻擊風險。其中 CloudFront、Cloudflare 和 Fastly 的受影響數量最多。
限制與緩解措施
儘管攻擊潛力巨大，但研究也指出某些限制。例如，放大倍數在併發串流達到 64 個左右時會達到峰值隨後下降，這可能是受限於 CDN 邊緣節點的 CPU 處理開銷。此外，目前的測試環境將來源伺服器限制在 100 Mbps，尚未測試更高容量伺服器的極限。
由於此漏洞存在於 CDN 的協議轉換邏輯中，來源伺服器端無法直接修復，所有的緩解措施必須由 CDN 供應商實施。研究人員建議的對策包括：限制 QPACK 動態表單個條目的最大尺寸（如 512 字節）、限制單一串流引用動態表的次數、強制執行解壓縮後 HTTP/1.1 請求的最大尺寸限制（如 64KB）、以及在開啟後端連線前先緩衝完整的 HTTP/3 請求。
目前 Baidu 和 Tencent 已確認報告並部署了部分修復措施，包括限制後端連線數量與動態表標頭尺寸。其他供應商則表示正在內部討論相關發現。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。