[[336656]]

HTTP/3是超文本傳輸協(xié)議（HTTP）的第三個正式版本，將改善網(wǎng)絡(luò)性能和穩(wěn)定性，解決各種安全隱私問題，但盡管如此，仍存在一些安全挑戰(zhàn)。

HTTP/3不再使用傳輸控制協(xié)議（TCP），相反，將使用2012年谷歌提出的QUIC傳輸協(xié)議。實際上，HTTP/3前身是HTTP-over-QUIC。

2018年10月，互聯(lián)網(wǎng)工程任務(wù)組（IETF） HTTP和QUIC工作組主席Mark Nottingham提出了將HTTP-over-QUIC更名為HTTP/3

QUIC是基于用戶數(shù)據(jù)包協(xié)議（UDP）連接的復(fù)用版本的傳輸層協(xié)議。與TCP不同，UDP不遵循TCP三向交握，而是使用單個UDP往返。因此，在用戶代理和Web服務(wù)器之間的每個連接都使用UDP，QUIC協(xié)議極大地改善了任何web組件的網(wǎng)絡(luò)性能。

同樣，QUIC依靠多路復(fù)用來在單個連接上無縫地管理用戶代理與服務(wù)器之間的多個交互，而沒有一個阻塞另一個，因此與以前的版本相比，有助于提高性能。從性能和穩(wěn)定性的角度考慮，HTTP/3似乎都有很大的優(yōu)勢。從安全性來說，HTTP/3有其先進性也有其局限性。

安全優(yōu)勢

1、端到端加密

TCP協(xié)議旨在確保在傳輸過程中進行有效負(fù)載加密，但是對于特定傳輸?shù)男畔⑷晕醇用埽赃@會引發(fā)許多安全和隱私問題。預(yù)防攻擊的對策不是在TCP堆棧上，而是在處理協(xié)議和網(wǎng)絡(luò)的網(wǎng)絡(luò)設(shè)備和中間盒上。此外，解析器可以克服負(fù)載均衡器和其他網(wǎng)絡(luò)設(shè)備中的這些問題，但它們也還存在嚴(yán)重的性能問題，并且可能會限制網(wǎng)絡(luò)發(fā)展速度和可靠性。

使用QUIC協(xié)議時，只有網(wǎng)段中的必填字段未加密，而其余信息默認(rèn)情況下是加密的。通過查看TCP和QUIC的網(wǎng)絡(luò)段，我們發(fā)現(xiàn)包括數(shù)據(jù)包標(biāo)志（數(shù)據(jù)包NR和ACK NR），窗口和選項的字段在QUIC中已加密，但在TCP中未加密。QUIC中建議加密有助于防止普遍存在的監(jiān)視攻擊（在HTTP / 3的前身中很普遍）以及協(xié)議工件和元數(shù)據(jù)、應(yīng)用程序數(shù)據(jù)的侵入式信息收集。

下面的圖1顯示了QUIC協(xié)議在網(wǎng)絡(luò)分析器工具Wireshark中的呈現(xiàn)方式。根據(jù)QUIC的網(wǎng)段，互聯(lián)網(wǎng)協(xié)議（IP）層保存源IP地址和目標(biāo)IP地址信息。UDP保留源端口和目標(biāo)端口，而QUIC包含公共標(biāo)志，數(shù)據(jù)包編號，連接ID和加密的有效負(fù)載。

圖1 Wireshark代碼段顯示QUIC協(xié)議的網(wǎng)段

2、TLS安全連接

為了在連接期間支持端到端加密，QUIC主要依賴于加密和傳輸層握手。由于QUIC直接與TLS 1.3 交互，因此它可用于所有原始連接的授權(quán)加密，并且沒有禁用TLS。QUIC還負(fù)責(zé)確保建立安全連接，同時考慮到所有原始連接的機密性和完整性保護。與HTTP / 2 + TLS實現(xiàn)不同，QUIC在其傳輸上下文中處理TLS握手和警報機制，這反過來又幫助QUIC利用從握手交換的密鑰來建立密碼保護。

如果我們從整體上考慮該協(xié)議，則TLS和QUIC之間存在兩個主要通信：

QUIC為TLS提供了穩(wěn)定的流抽象，通過QUIC發(fā)送和接收消息。

TLS使用以下內(nèi)容更新QUIC組件。

    1.秘密的、經(jīng)過身份驗證的加密算法和密鑰派生功能（KDF）

    2.數(shù)據(jù)包保護密鑰

    3.協(xié)議狀態(tài)更改（例如握手狀態(tài)、服務(wù)器證書）

與使用TLS的“ application_data”記錄的HTTP/2不同，QUIC使用STREAM幀，通過QUIC數(shù)據(jù)包形式展現(xiàn)。TLS握手以CRYPTO幀的形式形成，主要由連續(xù)流中的握手?jǐn)?shù)據(jù)組成。QUIC旨在并行發(fā)送數(shù)據(jù)包，有時會將不同的消息捆綁成一個消息并加密，因為這些消息具有相同的加密級別。此功能為網(wǎng)絡(luò)性能提供了極大的優(yōu)勢，同時確保在傳輸過程中應(yīng)用正確的加密模式。

3、完全正向保密性

當(dāng)在用戶代理和服務(wù)器之間交換臨時私鑰時，可以實現(xiàn)協(xié)議中的完全前向保密性（PFS）。用戶代理啟動的每個會話都使用新的唯一會話密鑰，并且它與先前的會話密鑰沒有任何關(guān)系。通過為每次傳輸使用單獨的會話密鑰，即使任何會話密鑰被泄露，來自較早或?qū)頃挼娜魏涡畔⒁膊粫艿狡茐摹募用芙嵌葋砜?，沒有密鑰交換可以提供完美前向保密性。但是，完全正向保密性，一個新術(shù)語對PFS的實現(xiàn)提供了可能。

QUIC使用TLS 1.3，該協(xié)議支持橢圓曲線（EC）DHE密鑰交換或有限字段上的預(yù)共享密鑰（PSK）和Diffie-Hellman（DH）。0-RTT密鑰交換提供了完全的正向保密性，因為加密規(guī)范僅接受通過0-RTT握手的前向安全連接。盡管TLS 1.2還支持前向保密性，但從技術(shù)上講，當(dāng)用戶代理發(fā)送由只有服務(wù)器已知的對稱密鑰保護的機密資料副本時，正向保密性在會話恢復(fù)期間會丟失。該協(xié)議甚至為用戶代理和服務(wù)器之間的初始消息提供了完全的正向保密。此外，由于QUIC協(xié)議不支持長期密鑰，因此QUIC借助TLS 1.3可以使用其協(xié)議層為應(yīng)用程序提供完全正向保密功能。

4、重放攻擊防護

除了隨機數(shù)，QUIC實現(xiàn)還用于存儲密鑰派生的客戶端值。服務(wù)器會識別并拒絕具有相同密鑰派生值和隨機數(shù)的任何重復(fù)請求。考慮到用戶代理和服務(wù)器之間的協(xié)議通信開銷，這種設(shè)計被稱為性能噩夢。從理論上講，該解決方案看似適用，但是在實踐中，該協(xié)議可能會變得很占內(nèi)存并導(dǎo)致性能問題。當(dāng)前的設(shè)計不是最好的，但是從協(xié)議層面來說，這會防止任何服務(wù)器多次接受同一密鑰。同樣，QUIC在初始步驟中不提供重放保護，而是在服務(wù)器初始回復(fù)后立即開始保護。QUIC是讓初始交易能得到應(yīng)用程序保護并減少協(xié)議所占內(nèi)存?？紤]到Web組件可能會使用從會話密鑰派生的密鑰，因此在此階段可能會發(fā)生重放攻擊。但是，可以在應(yīng)用程序?qū)用媸褂妙A(yù)防措施來減輕這種情況。

5、IP欺騙保護

QUIC在握手期間支持地址驗證，并且需要簽名的地址證明，從而消除了任何IP欺騙攻擊。IP地址欺騙問題主要在QUIC中通過廣泛利用“源地址令牌”來解決，“源地址令牌”是服務(wù)器的經(jīng)過身份驗證的加密塊，其中包含用戶代理的IP地址和服務(wù)器的時間戳。用戶代理可以重復(fù)使用服務(wù)器生成的源地址令牌，除非連接更改、IP地址不在變化。由于源地址令牌用作承載令牌，因此它們可以反復(fù)使用，并且可以繞過服務(wù)器設(shè)置的任何IP地址限制。由于服務(wù)器僅響應(yīng)令牌中的IP地址，因此即使是被盜的cookie或令牌也不會成功進行IP欺騙。

6、防止SSL降級

TLS 1.3可以防止TLS降級攻擊，因為該協(xié)議規(guī)定了所有握手通信的密鑰哈希，并且要求握手接收方驗證發(fā)送的密鑰哈希。在握手過程中，任何檢測到的對客戶端功能的篡改嘗試都將導(dǎo)致握手終止并出現(xiàn)錯誤。此外，檢測還涉及用戶代理與服務(wù)器之間的證書驗證消息，包括有關(guān)特定連接的所有先前消息的PKCS RSA哈希簽名。QUIC中的校驗和實現(xiàn)將成功防止TLS降級攻擊。

[[336657]]

安全挑戰(zhàn)

1、0-RTT恢復(fù)漏洞

HTTP / 3的最大優(yōu)勢之一是0-RTT恢復(fù)，它可以極大地提高連接速度并減少延遲。但是，僅當(dāng)成功建立了先前的連接，并且當(dāng)前交易使用在上一次連接期間建立了預(yù)共享機密時，這一優(yōu)勢才發(fā)揮作用。

0-RTT恢復(fù)功能存在一些安全方面的缺點。最常見的攻擊媒介之一是重放攻擊，當(dāng)對手重新發(fā)送初始數(shù)據(jù)包時可能會造成這種攻擊。在特定的情況下，這可能會迫使服務(wù)器認(rèn)為該請求來自先前已知的客戶端。恢復(fù)0-RTT的另一個安全缺點是完全前向保密的部分失效。如果對手破壞了令牌，那么他們就可以解密用戶代理發(fā)送的0-RTT通信內(nèi)容。

2、連接ID操縱攻擊

連接ID操縱攻擊要求將攻擊者處在用戶代理與服務(wù)器之間。他們可以在交換客戶端和服務(wù)器問候消息的初始握手期間操縱連接ID。握手將照常進行，服務(wù)器假定已建立連接，但是用戶代理將無法解密，因為連接ID需要加密密鑰派生過程的輸入步驟，并且用戶代理和服務(wù)器將計算不同的加密鍵。用戶代理最終將超時，并向服務(wù)器發(fā)送錯誤消息，告知連接已終止。由于客戶端使用原始的加密密鑰將錯誤消息加密到服務(wù)器，因此服務(wù)器將無法解密，并且將保持連接狀態(tài)，直到空閑連接超時（通常在10分鐘內(nèi)）到期為止。

當(dāng)大規(guī)模執(zhí)行時，相同的攻擊可能會對服務(wù)器造成拒絕服務(wù)攻擊，并保留多個連接，直到連接狀態(tài)過期。保持連接有效的另一種攻擊方法是更改其他參數(shù)，例如源地址令牌，從而防止客戶端建立任何連接。

3、UDP放大攻擊

為了成功進行放大攻擊，攻擊者必須欺騙受害者的IP地址，并將UDP請求發(fā)送到服務(wù)器。如果服務(wù)器發(fā)回更重要的UDP響應(yīng)，則攻擊者可以大規(guī)模利用此服務(wù)器行為并創(chuàng)建DDOS攻擊情形。

具體來說，在QUIC中，當(dāng)對手從目標(biāo)接受地址驗證令牌并釋放最初用于生成令牌的IP地址時，就會發(fā)生UDP放大攻擊。攻擊者可以使用相同的IP地址將0-RTT連接發(fā)送回服務(wù)器，該IP地址可能已被改為指向不同的端點。通過執(zhí)行此設(shè)置，攻擊者可以潛在地指示服務(wù)器向受害服務(wù)器發(fā)送大量流量。為了防止這種攻擊，HTTP / 3具有速率限制功能和短暫的驗證令牌，可以充當(dāng)DDOS攻擊的補償控制，同時部分緩解攻擊情形。

4、流量耗盡型攻擊

當(dāng)對手有意啟動多個連接流時，就會發(fā)生流耗盡攻擊，這可能導(dǎo)致端點耗盡。攻擊者可以通過反復(fù)提交大量請求來利用窮盡序列。盡管特定的傳輸參數(shù)可能會限制并發(fā)活動流的數(shù)量，但是在某些情況下，可能會故意將服務(wù)器配置設(shè)置為更高數(shù)值。由于服務(wù)器的協(xié)議配置增加了協(xié)議性能，因此受害服務(wù)器可能成為此類攻擊的目標(biāo)。

5、連接重置攻擊

連接重置攻擊主要是向受害者發(fā)送無狀態(tài)重置，從而可能產(chǎn)生類似于TCP重置注入攻擊的拒絕服務(wù)攻擊。如果攻擊者可以獲得具有特定連接ID的連接生成的重置令牌，則可能存在潛在的攻擊媒介。最后，攻擊者可以使用生成的令牌重置具有相同連接ID的活動連接，從而使服務(wù)器等待連接，直到發(fā)生超時為止。如果大規(guī)模進行此攻擊，則服務(wù)器必須大量消耗其資源，以等待連接完成。

6、QUIC版本降級攻擊

QUIC數(shù)據(jù)包保護為通信中的所有數(shù)據(jù)包（版本協(xié)商數(shù)據(jù)包除外）提供身份驗證和加密。版本協(xié)商數(shù)據(jù)包旨在協(xié)商用戶代理和服務(wù)器之間QUIC的版本。該功能可能允許攻擊者將版本降級到QUIC的不安全版本。該攻擊目前暫時不會發(fā)生，因為只有QUIC的一個版本，但是將來需要注意。

7、缺少監(jiān)視支持

盡管一些用戶代理，服務(wù)器和信譽良好的網(wǎng)站支持HTTP3/QUIC，但是許多網(wǎng)絡(luò)設(shè)備（例如反向/正向代理，負(fù)載均衡器，Web應(yīng)用程序防火墻和安全事件監(jiān)視工具）并不完全支持HTTP/3。與TCP不同，QUIC連接中不需要套接字，這使得檢測主機和惡意連接變得更加困難。惡意攻擊者可能能夠通過QUIC中繼惡意有效載荷并執(zhí)行數(shù)據(jù)泄露攻擊，并且保持隱身狀態(tài)，因為大多數(shù)檢測工具無法檢測到QUIC流量。

QUIC的歷史

2016年，互聯(lián)網(wǎng)工程任務(wù)組（IETF）開始標(biāo)準(zhǔn)化Google的QUIC，并宣布IETF QUIC成為新HTTP/3版本的基礎(chǔ)。但是，出于性能和安全方面的考慮，IETF QUIC與原始QUIC設(shè)計大相徑庭。

TCP上的傳統(tǒng)Web流量需要三向握手。QUIC使用UDP，由于往返次數(shù)減少和發(fā)送的數(shù)據(jù)包減少，因此延遲減少，從而加快了網(wǎng)絡(luò)流量傳輸。UDP除了速度更快之外，還具有其他優(yōu)點，包括連接遷移、改進延遲、擁塞控制和內(nèi)置加密。根據(jù)Google的說法， “與TCP + TLS的1-3次往返相比， QUIC握手通常需要零往返來發(fā)送有效負(fù)載。” 第一個連接需要一個往返，而隨后的連接則不需要任何往返。同樣，由于QUIC用于多路復(fù)用操作，因此與TCP相比，它在數(shù)據(jù)包丟失方面做得更好，并且握手速度更快。

Google的QUIC版本現(xiàn)在是gQUIC。從gQUIC進化的HTTP/3，具備了重大的改進，并得到IETF工作組的貢獻和增強。盡管從技術(shù)上講HTTP/3是完整的應(yīng)用程序協(xié)議，但QUIC指的是基礎(chǔ)傳輸協(xié)議，它不限于服務(wù)Web流量。UDP是無連接的，不是很可靠。QUIC通過在UDP上添加類似于TCP的堆棧，來添加可靠的連接，并在其之上重新發(fā)送具有流控制功能的方式來克服這些限制，同時解決了TCP的行頭阻塞問題。

HTTP/3使用UDP，類似于HTTP/2使用TCP的方式。每個連接都有幾個并行流，這些并行流用于通過單個連接同時傳輸數(shù)據(jù)，而不會影響其他流。因此，與TCP不同，為特定的單個流承載數(shù)據(jù)的丟失數(shù)據(jù)包只會影響該特定的流。然后，每個流幀都可以在到達(dá)時立即分配給該流，因此可以在不丟失任何流的情況下繼續(xù)在應(yīng)用程序中重新組合。QUIC的這種連接建立策略是通過加密和傳輸握手的組合來實現(xiàn)的。

和HTTP/2的比較分析

QUIC旨在通過減輕HTTP/2的數(shù)據(jù)包丟失和延遲問題來提高性能。雖然HTTP/2對每個數(shù)據(jù)來源使用單個TCP連接，但這會導(dǎo)致行頭阻塞問題。例如，一個請求的對象可能會停滯在另一個遭受丟失的對象之后，直到該對象恢復(fù)為止。QUIC通過將HTTP/2的流層向下推送到傳輸層來解決此問題，從而避免了應(yīng)用程序?qū)雍蛡鬏攲拥膯栴}。HTTP/3還支持多路復(fù)用，在與TLS直接集成的同時，提供獨立于其他連接請求的請求。盡管HTTP/2和HTTP/3的工作方式相似，但以下是HTTP/2和HTTP/3的一些重要區(qū)別。

從網(wǎng)絡(luò)堆棧的角度來看，HTTP/2廣泛使用了符合HTTP標(biāo)準(zhǔn)的TLS 1.2+，底層的TCP充當(dāng)了傳輸協(xié)議。但是，在HTTP/3中，默認(rèn)情況下，除了QUIC以外，還使用TLS 1.3，而UDP是傳輸協(xié)議。下圖說明了QUIC在網(wǎng)絡(luò)協(xié)議堆棧中的位置。相比之下，以前的版本使用TLS 1.2，并使用TCP的擁塞控制丟失恢復(fù)功能，而HTTP/2處理多流功能。

圖2：QUIC在網(wǎng)絡(luò)協(xié)議堆棧中的位置

連接ID的優(yōu)勢

TCP連接即利用數(shù)據(jù)源和目標(biāo)網(wǎng)絡(luò)實體（主要是地址和端口）來標(biāo)識特定連接。但是，QUIC連接使用連接ID，它是64位隨機生成的客戶端標(biāo)識符。這項更改對于當(dāng)前的Web技術(shù)非常有利，主要是因為要求它們支持用戶的移動性。如果用戶從Wi-Fi網(wǎng)絡(luò)移動到蜂窩網(wǎng)絡(luò)，則HTTP/2 TCP協(xié)議將需要基于當(dāng)前地址建立新的連接。但是，由于HTTP/3 QUIC協(xié)議使用隨機連接ID，因此當(dāng)從蜂窩網(wǎng)絡(luò)轉(zhuǎn)移到Wi-Fi連接時，HTTP/3上的客戶端更改IP地址將繼續(xù)使用現(xiàn)有的連接ID而不會中斷。

從協(xié)議的角度來看，連接ID提供了其他好處。服務(wù)器和用戶代理可以使用連接ID識別原始連接和重傳連接，并避免TCP中普遍存在的重傳歧義問題。

結(jié)論

QUIC已獲得多數(shù)瀏覽器的支持。YouTube和Facebook等重要網(wǎng)站已啟用該功能，可以更快地加載頁面。在撰寫本文時，目前只有4％的頂級網(wǎng)站支持QUIC。微軟已經(jīng)宣布，他們將在內(nèi)核中交付帶有通用QUIC庫MsQuic的Windows，以支持各種收件箱功能。

QUIC和HTTP/3旨在滿足當(dāng)今互聯(lián)網(wǎng)網(wǎng)絡(luò)性能、可靠性和安全性的目標(biāo)。強制性支持TLS 1.3的安全性得到了顯著改善，從而解決了HTTP/2和早期版本的HTTP的弱點。在HTTP/3傳輸過程中使用端到端加密有助于抵御攻擊者和數(shù)據(jù)聚合者的一些隱私問題。盡管存在一些弱點，但從性能和安全性角度來看，HTTP/3仍將繼續(xù)發(fā)展，不管怎么說都是對HTTP/2的重大改進。