好啦，咱閣轉來講 HTTP/1.1 矣，咱的頭一篇遐就是有講著 HTTP/1.1 的代誌矣，啊彼敢毋是 2019 的代誌？佇彼當陣足鑠奅，毋過 tsín 攏 2025 矣，愛修的物件敢毋是攏早就予人補了了矣？

無nooh，佇今年咱 Kettle 大的就有發表這篇「HTTP/1.1 Must Die」，口氣是蓋大毋過，誠實有本錢按呢講。

彼篇研究內面是講，HTTP/1.1 伊的設計生本就有一大堆欠點，咱按呢補永遠是會補袂煞。這篇研究毋但發現濟濟新的攻擊手法，閣共 Akamai、Cloudflare 這寡 CDN 大廠攏鑽破去，影響超過數千萬的網站。

好，咱就做伙來熟似這場「終局之戰」是生怎樣。

HTTP/1.1 根頭就無在

HTTP/1.1 這个協定有一个足害的所在，就是伊無一个清楚的理路來分別逐个網路請求的界線。 伊是佇同一个 TCP 連線頂懸，共一堆請求的純文字資料敆做伙送出去。啊問題就是像咱上代先有講過的伊分袂清楚嘛，Content-Length (CL) 佮 Transfer-Encoding (TE) 會當予咱判斷無毋著，猶毋過逐个若鬥做伙閣處理理路無仝就會出代誌。這部份咱以早就講誠濟矣。

像講這款 CL.TE 的攻擊

POST / HTTP/1.1
Host: <redacted>
Transfer-Encoding: chunked <--  backend 看遮
Content-length: 35 <-- frontend 看遮

0

GET /robots.txt HTTP/1.1 <-- 煞變做後一个請求的開頭，後一个連線入來會看著 robots.txt 的內容
X: y

咱這馬凡勢已經是看無啥會著這款基本漏縫佇咧外口現 hia-hia 矣，你無定會感覺咱這馬攏已經安全矣，毋過，一切攏是一寡 WAF、無在、無補著點的 patch 予咱錯覺。

Desync 的新家私

好，舊的招數濟濟 WAF 攏已經會共閘掉矣。毋過 Kettle 的新研究發現閣較厲害、閣較歹揣的步數。

0.CL Desync：拍袂破的局煞有解矣

有一種狀況叫做 H-V (Hidden-Visible)，就是講有一个標頭，頭前的 server 看袂著，後壁的 server 看會著。若咱用這个特性來囥 Content-Length，就會造成 0.CL desync。意思是，頭前 server 無看著 CL，認為這是一个無 body 的請求；後壁 server 有看著 CL，就一直咧等 body 送入來。結果就是兩爿攏咧硞硞等，等到 timeout 攻擊煞就失敗。這就是所謂的 deadlock。

欲按怎破解？揣一个會當予後壁的 server「提早回應」（early-response）的破口就著！

一个足趣味的例，就是針對用 Windows IIS 的 server。佇 Windows 內底，有一寡保留的檔案名袂當用，親像 CON、NUL。若你對一个 IIS server 請求一个號做 .../con 的路徑，伊會隨應一个錯誤，毋免等甲咱的 body 送予了。

利用這點，攻擊就會變做按呢：

# 攻擊請求
GET /con HTTP/1.1
Host: <redacted>
Content-Length: 7

# 下一个衰尾道人的請求
GET / HTTP/1.1
Host: <redacted>

• 前端：伊無看著 Content-Length，送出 GET /con 就成功結束矣。
• 後端：伊有看著 Content-Length: 7，而且因為是 /con，伊就先共應矣，毋過連線猶未斷去，繼續等 7 个 bytes 的 body。這時，後一个使用者的請求 GET / 就會夆當做 body 食入去，造成後壁 server 發生錯誤，應一个 400 Bad Request。

按呢咱就證明 0.CL desync 是會當發生的！

Expect ：衝懸複雜度

這篇文章上媠氣的發現，就是利用 Expect: 100-continue 這个標頭。 這本成是一个用來改良的設計，就是 client 會先送一个佮　 Expect 的標頭去 server，問講「我等下欲送一个足大khian的 body，你敢會收？」，server 若應 100 Continue，client 才真正開始送 body。

這个過程伊本身就足複雜，經過 proxy 了後閣較慘。Kettle 發現，真濟 server 對 Expect 的處理攏出重耽，造成各樣新型的 desync 攻擊。

CL.0 desync via obfuscated Expect - Akamai CDN 的例

這个攻擊影響足大，連 Akamai 這款的 CDN 嘛著。攻擊者會當對 auth.lastpass.com 這个用 Akamai CDN 的網站，偷渡內容入去予使用者。

OPTIONS /anything HTTP/1.1
Host: auth.lastpass.com
Expect:  100-continue  # <-- 頭前有空格仔，這就是一種 obfuscation
Content-Length: 39

GET / HTTP/1.1
Host: www.sky.com
X: X

這个請求會造成 CL.0 desync，後壁彼个 GET / 的請求會夆偷偷囥佇連線內底。後一个使用者連入來時，就會先收到 www.sky.com 的回應，予伊看著毋是 LastPass 的內容。用這个步數，攻擊者就有可能偷著使用者的口座暗號。

阿是欲按怎守(x) 咱來共 HTTP/1.1 擲掉 (o)

這篇研究上重要的結論，毋是揣著幾仔个仔漏洞爾爾，是證明 HTTP/1.1 這个協定本身就是濟濟漏縫的根源。 因為伊對「請求邊界」的定義傷過模糊，予一寡小可的實作錯誤，就會成做痟大的安全漏縫。伊講，這六年來的經驗證明欲一个一个補破網是補袂了的。

真正的解法是啥？

毋通閣相信啥物 WAF 會當完美解決問題的講法矣，彼攏是治標袂治本。

共 HTTP/1.1 擲掉去用 HTTP 2 才是正途啦。