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

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

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

[[335081]]

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

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

安全優(yōu)勢(shì)

1. 端到端加密

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

使用QUIC協(xié)議時(shí)，只有網(wǎng)段中的必填字段未加密，而其余信息默認(rèn)情況下是加密的。通過(guò)查看TCP和QUIC的網(wǎng)絡(luò)段，我們發(fā)現(xiàn)包括數(shù)據(jù)包標(biāo)志(數(shù)據(jù)包NR和ACK NR)，窗口和選項(xiàng)的字段在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ù)包編號(hào)，連接ID和加密的有效負(fù)載。

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

2. TLS安全連接

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

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

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

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

• 秘密的、經(jīng)過(guò)身份驗(yàn)證的加密算法和密鑰派生功能(KDF)
• 數(shù)據(jù)包保護(hù)密鑰
• 協(xié)議狀態(tài)更改(例如握手狀態(tài)、服務(wù)器證書(shū))

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

3. 完全正向保密性

當(dāng)在用戶(hù)代理和服務(wù)器之間交換臨時(shí)私鑰時(shí)，可以實(shí)現(xiàn)協(xié)議中的完全前向保密性(PFS)。用戶(hù)代理啟動(dòng)的每個(gè)會(huì)話(huà)都使用新的唯一會(huì)話(huà)密鑰，并且它與先前的會(huì)話(huà)密鑰沒(méi)有任何關(guān)系。通過(guò)為每次傳輸使用單獨(dú)的會(huì)話(huà)密鑰，即使任何會(huì)話(huà)密鑰被泄露，來(lái)自較早或?qū)?lái)會(huì)話(huà)的任何信息也不會(huì)受到破壞。從加密角度來(lái)看，沒(méi)有密鑰交換可以提供完美前向保密性。但是，完全正向保密性，一個(gè)新術(shù)語(yǔ)對(duì)PFS的實(shí)現(xiàn)提供了可能。

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

4. 重放攻擊防護(hù)

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

5. IP欺騙保護(hù)

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

6. 防止SSL降級(jí)

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

安全挑戰(zhàn)

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

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

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

2. 連接ID操縱攻擊

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

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

3. UDP放大攻擊

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

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

4. 流量耗盡型攻擊

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

5. 連接重置攻擊

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

6. QUIC版本降級(jí)攻擊

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

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

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

QUIC的歷史

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

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

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

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

和HTTP/2的比較分析

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

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

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

連接ID的優(yōu)勢(shì)

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

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

結(jié)論

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

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