91久久婷婷亚洲精品成人,丁香五月天色婷婷,蜜桃91av操逼,俺去啦俺去也www官网,91AV一区二区三区,人人操,人人爱黄色,超碰在线青青草,国产激情在线视频网站

作者：IT影子
鏈接：https://www.jianshu.com/p/b0b3c6df1a16

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é)議旨在確保在傳輸過程中進行有效負載加密，但是對于特定傳輸?shù)男畔⑷晕醇用?，所以這會引發(fā)許多安全和隱私問題。預(yù)防攻擊的對策不是在TCP堆棧上，而是在處理協(xié)議和網(wǎng)絡(luò)的網(wǎng)絡(luò)設(shè)備和中間盒上。此外，解析器可以克服負載均衡器和其他網(wǎng)絡(luò)設(shè)備中的這些問題，但它們也還存在嚴重的性能問題，并且可能會限制網(wǎng)絡(luò)發(fā)展速度和可靠性。使用QUIC協(xié)議時，只有網(wǎng)段中的必填字段未加密，而其余信息默認情況下是加密的。通過查看TCP和QUIC的網(wǎng)絡(luò)段，我們發(fā)現(xiàn)包括數(shù)據(jù)包標志（數(shù)據(jù)包NR和ACK NR），窗口和選項的字段在QUIC中已加密，但在TCP中未加密。QUIC中建議加密有助于防止普遍存在的監(jiān)視攻擊（在HTTP / 3的前身中很普遍）以及協(xié)議工件和元數(shù)據(jù)、應(yīng)用程序數(shù)據(jù)的侵入式信息收集。搜索公眾號：互聯(lián)網(wǎng)架構(gòu)師，回復(fù)“2T”，送你一份架構(gòu)師寶典。下面的圖1顯示了QUIC協(xié)議在網(wǎng)絡(luò)分析器工具Wireshark中的呈現(xiàn)方式。根據(jù)QUIC的網(wǎng)段，互聯(lián)網(wǎng)協(xié)議（IP）層保存源IP地址和目標IP地址信息。UDP保留源端口和目標端口，而QUIC包含公共標志，數(shù)據(jù)包編號，連接ID和加密的有效負載。

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

2.TLS安全連接

為了在連接期間支持端到端加密，QUIC主要依賴于加密和傳輸層握手。由于QUIC直接與TLS 1.3 交互，因此它可用于所有原始連接的授權(quán)加密，并且沒有禁用TLS。QUIC還負責確保建立安全連接，同時考慮到所有原始連接的機密性和完整性保護。關(guān)注公眾號：互聯(lián)網(wǎng)架構(gòu)師，回復(fù)“2T”，送你一份架構(gòu)師寶典。與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ù)流中的握手數(shù)據(jù)組成。QUIC旨在并行發(fā)送數(shù)據(jù)包，有時會將不同的消息捆綁成一個消息并加密，因為這些消息具有相同的加密級別。此功能為網(wǎng)絡(luò)性能提供了極大的優(yōu)勢，同時確保在傳輸過程中應(yīng)用正確的加密模式。

3.完全正向保密性

當在用戶代理和服務(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ù)上講，當用戶代理發(fā)送由只有服務(wù)器已知的對稱密鑰保護的機密資料副本時，正向保密性在會話恢復(fù)期間會丟失。該協(xié)議甚至為用戶代理和服務(wù)器之間的初始消息提供了完全的正向保密。此外，由于QUIC協(xié)議不支持長期密鑰，因此QUIC借助TLS 1.3可以使用其協(xié)議層為應(yīng)用程序提供完全正向保密功能。

除了隨機數(shù)，QUIC實現(xiàn)還用于存儲密鑰派生的客戶端值。服務(wù)器會識別并拒絕具有相同密鑰派生值和隨機數(shù)的任何重復(fù)請求?？紤]到用戶代理和服務(wù)器之間的協(xié)議通信開銷，這種設(shè)計被稱為性能噩夢。從理論上講，該解決方案看似適用，但是在實踐中，該協(xié)議可能會變得很占內(nèi)存并導致性能問題。當前的設(shè)計不是最好的，但是從協(xié)議層面來說，這會防止任何服務(wù)器多次接受同一密鑰。同樣，QUIC在初始步驟中不提供重放保護，而是在服務(wù)器初始回復(fù)后立即開始保護。QUIC是讓初始交易能得到應(yīng)用程序保護并減少協(xié)議所占內(nèi)存。關(guān)注公眾號：互聯(lián)網(wǎng)架構(gòu)師，回復(fù)“2T”，送你一份架構(gòu)師寶典。考慮到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ā)送的密鑰哈希。在握手過程中，任何檢測到的對客戶端功能的篡改嘗試都將導致握手終止并出現(xiàn)錯誤。此外，檢測還涉及用戶代理與服務(wù)器之間的證書驗證消息，包括有關(guān)特定連接的所有先前消息的PKCS RSA哈希簽名。QUIC中的校驗和實現(xiàn)將成功防止TLS降級攻擊。

安全挑戰(zhàn)

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è)備（例如反向/正向代理，負載均衡器，Web應(yīng)用程序防火墻和安全事件監(jiān)視工具）并不完全支持HTTP / 3。與TCP不同，QUIC連接中不需要套接字，這使得檢測主機和惡意連接變得更加困難。惡意攻擊者可能能夠通過QUIC中繼惡意有效載荷并執(zhí)行數(shù)據(jù)泄露攻擊，并且保持隱身狀態(tài)，因為大多數(shù)檢測工具無法檢測到QUIC流量。關(guān)注公眾號：互聯(lián)網(wǎng)架構(gòu)師，回復(fù)“2T”，送你一份架構(gòu)師寶典。

QUIC的歷史

2016年，互聯(lián)網(wǎng)工程任務(wù)組（IETF）開始標準化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ā)送有效負載?！?第一個連接需要一個往返，而隨后的連接則不需要任何往返。同樣，由于QUIC用于多路復(fù)用操作，因此與TCP相比，它在數(shù)據(jù)包丟失方面做得更好，并且握手速度更快。關(guān)注公眾號：互聯(lián)網(wǎng)架構(gòu)師，回復(fù)“2T”，送你一份架構(gòu)師寶典。

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ù)包只會影響該特定的流。然后，每個流幀都可以在到達時立即分配給該流，因此可以在不丟失任何流的情況下繼續(xù)在應(yīng)用程序中重新組合。QUIC的這種連接建立策略是通過加密和傳輸握手的組合來實現(xiàn)的。

和HTTP/2的比較分析

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