HTTP/3是超文本傳輸協議（HTTP）的第三個正式版本，將改善網絡性能和穩定性，解決各種安全隱私問題，但儘管如此，仍存在一些安全挑戰。

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

2018年10月，互聯網工程任務組（IETF） HTTP和QUIC工作組主席Mark Nottingham提出了將HTTP-over-QUIC更名爲HTTP/3

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

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

安全優勢 1.端到端加密

TCP協議旨在確保在傳輸過程中進行有效負載加密，但是對於特定傳輸的信息仍未加密，所以這會引發許多安全和隱私問題。預防攻擊的對策不是在TCP堆棧上，而是在處理協議和網絡的網絡設備和中間盒上。此外，解析器可以克服負載均衡器和其他網絡設備中的這些問題，但它們也還存在嚴重的性能問題，並且可能會限制網絡發展速度和可靠性。

使用QUIC協議時，只有網段中的必填字段未加密，而其餘信息默認情況下是加密的。通過查看TCP和QUIC的網絡段，我們發現包括數據包標誌（數據包NR和ACK NR），窗口和選項的字段在QUIC中已加密，但在TCP中未加密。QUIC中建議加密有助於防止普遍存在的監視攻擊（在HTTP / 3的前身中很普遍）以及協議工件和元數據、應用程序數據的侵入式信息收集。

下面的圖1顯示了QUIC協議在網絡分析器工具Wireshark中的呈現方式。根據QUIC的網段，互聯網協議（IP）層保存源IP地址和目標IP地址信息。UDP保留源端口和目標端口，而QUIC包含公共標誌，數據包編號，連接ID和加密的有效負載。

圖1 Wireshark代碼段顯示QUIC協議的網段 2.TLS安全連接

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

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

QUIC爲TLS提供了穩定的流抽象，通過QUIC發送和接收消息。

TLS使用以下內容更新QUIC組件。

1.祕密的、經過身份驗證的加密算法和密鑰派生功能（KDF）

2.數據包保護密鑰

3.協議狀態更改（例如握手狀態、服務器證書）

與使用TLS的“ application_data”記錄的HTTP/2不同，QUIC使用STREAM幀，通過QUIC數據包形式展現。TLS握手以CRYPTO幀的形式形成，主要由連續流中的握手數據組成。QUIC旨在並行發送數據包，有時會將不同的消息捆綁成一個消息並加密，因爲這些消息具有相同的加密級別。此功能爲網絡性能提供了極大的優勢，同時確保在傳輸過程中應用正確的加密模式。

3.完全正向保密性

當在用戶代理和服務器之間交換臨時私鑰時，可以實現協議中的完全前向保密性（PFS）。用戶代理啓動的每個會話都使用新的唯一會話密鑰，並且它與先前的會話密鑰沒有任何關係。通過爲每次傳輸使用單獨的會話密鑰，即使任何會話密鑰被泄露，來自較早或將來會話的任何信息也不會受到破壞。從加密角度來看，沒有密鑰交換可以提供完美前向保密性。但是，完全正向保密性，一個新術語對PFS的實現提供了可能。

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

4.重放攻擊防護

除了隨機數，QUIC實現還用於存儲密鑰派生的客戶端值。服務器會識別並拒絕具有相同密鑰派生值和隨機數的任何重複請求。考慮到用戶代理和服務器之間的協議通信開銷，這種設計被稱爲性能噩夢。從理論上講，該解決方案看似適用，但是在實踐中，該協議可能會變得很佔內存並導致性能問題。當前的設計不是最好的，但是從協議層面來說，這會防止任何服務器多次接受同一密鑰。同樣，QUIC在初始步驟中不提供重放保護，而是在服務器初始回覆後立即開始保護。QUIC是讓初始交易能得到應用程序保護並減少協議所佔內存。考慮到Web組件可能會使用從會話密鑰派生的密鑰，因此在此階段可能會發生重放攻擊。但是，可以在應用程序層面使用預防措施來減輕這種情況。

5.IP欺騙保護

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

6.防止SSL降級

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

安全挑戰 1.0-RTT恢復漏洞

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

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

2.連接ID操縱攻擊

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

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

2.UDP放大攻擊

爲了成功進行放大攻擊，攻擊者必須欺騙受害者的IP地址，並將UDP請求發送到服務器。如果服務器發回更重要的UDP響應，則攻擊者可以大規模利用此服務器行爲並創建DDOS攻擊情形。

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

3.流量耗盡型攻擊

當對手有意啓動多個連接流時，就會發生流耗盡攻擊，這可能導致端點耗盡。攻擊者可以通過反覆提交大量請求來利用窮盡序列。儘管特定的傳輸參數可能會限制併發活動流的數量，但是在某些情況下，可能會故意將服務器配置設置爲更高數值。由於服務器的協議配置增加了協議性能，因此受害服務器可能成爲此類攻擊的目標。

4.連接重置攻擊

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

5.QUIC版本降級攻擊

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

6.缺少監視支持

儘管一些用戶代理，服務器和信譽良好的網站支持HTTP3/QUIC，但是許多網絡設備（例如反向/正向代理，負載均衡器，Web應用程序防火牆和安全事件監視工具）並不完全支持HTTP/3。與TCP不同，QUIC連接中不需要套接字，這使得檢測主機和惡意連接變得更加困難。惡意攻擊者可能能夠通過QUIC中繼惡意有效載荷並執行數據泄露攻擊，並且保持隱身狀態，因爲大多數檢測工具無法檢測到QUIC流量。

QUIC的歷史

2016年，互聯網工程任務組（IETF）開始標準化Google的QUIC，並宣佈IETF QUIC成爲新HTTP/3版本的基礎。但是，出於性能和安全方面的考慮，IETF QUIC與原始QUIC設計大相徑庭。

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

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

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

和HTTP/2的比較分析

QUIC旨在通過減輕HTTP/2的數據包丟失和延遲問題來提高性能。雖然HTTP/2對每個數據來源使用單個TCP連接，但這會導致行頭阻塞問題。例如，一個請求的對象可能會停滯在另一個遭受丟失的對象之後，直到該對象恢復爲止。QUIC通過將HTTP/2的流層向下推送到傳輸層來解決此問題，從而避免了應用程序層和傳輸層的問題。HTTP/3還支持多路複用，在與TLS直接集成的同時，提供獨立於其他連接請求的請求。儘管HTTP/2和HTTP/3的工作方式相似，但以下是HTTP/2和HTTP/3的一些重要區別。區別HTTP/2HTTP/3傳輸TCP基於UDP的QUIC流層應用傳輸默認加密無有獨立流無有報頭壓縮HPACKQPACK握手更快的0-RTTTCP+TLS的1-3RTT連接消除無有擁塞控制損失恢復由TCP執行由QUIC執行

從網絡堆棧的角度來看，HTTP/2廣泛使用了符合HTTP標準的TLS 1.2+，底層的TCP充當了傳輸協議。但是，在HTTP/3中，默認情況下，除了QUIC以外，還使用TLS 1.3，而UDP是傳輸協議。下圖說明了QUIC在網絡協議堆棧中的位置。相比之下，以前的版本使用TLS 1.2，並使用TCP的擁塞控制丟失恢復功能，而HTTP/2處理多流功能。

圖2：QUIC在網絡協議堆棧中的位置

連接ID的優勢

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

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

結論

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

QUIC和HTTP/3旨在滿足當今互聯網網絡性能、可靠性和安全性的目標。強制性支持TLS 1.3的安全性得到了顯着改善，從而解決了HTTP/2和早期版本的HTTP的弱點。在HTTP/3傳輸過程中使用端到端加密有助於抵禦攻擊者和數據聚合者的一些隱私問題。儘管存在一些弱點，但從性能和安全性角度來看，HTTP/3仍將繼續發展，不管怎麼說都是對HTTP/2的重大改進。

相關文章