上一篇：深夜看了張一鳴的微網誌，讓我越想越後怕
作者：IT影子
HTTP/3不再使用傳輸控制協定（TCP），相反，将使用2012年谷歌提出的QUIC傳輸協定。實際上，HTTP/3前身是HTTP-over-QUIC。2018年10月，網際網路工程任務組（IETF） HTTP和QUIC工作組主席Mark Nottingham提出了将HTTP-over-QUIC更名為HTTP/3QUIC是基于使用者資料包協定（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的前身中很普遍）以及協定工件和中繼資料、應用程式資料的侵入式資訊收集。搜尋公衆号：網際網路架構師，回複“2T”，送你一份架構師寶典。下面的圖1顯示了QUIC協定在網絡分析器工具Wireshark中的呈現方式。根據QUIC的網段，網際網路協定（IP）層儲存源IP位址和目标IP位址資訊。UDP保留源端口和目标端口，而QUIC包含公共标志，資料包編号，連接配接ID和加密的有效負載。
圖1 Wireshark代碼段顯示QUIC協定的網段
2.TLS安全連接配接
為了在連接配接期間支援端到端加密，QUIC主要依賴于加密和傳輸層握手。由于QUIC直接與TLS 1.3 互動，是以它可用于所有原始連接配接的授權加密，并且沒有禁用TLS。QUIC還負責確定建立安全連接配接，同時考慮到所有原始連接配接的機密性和完整性保護。關注公衆号：網際網路架構師，回複“2T”，送你一份架構師寶典。與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是讓初始交易能得到應用程式保護并減少協定所占記憶體。關注公衆号：網際網路架構師，回複“2T”，送你一份架構師寶典。考慮到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分鐘内）到期為止。
當大規模執行時，相同的攻擊可能會對伺服器造成拒絕服務攻擊，并保留多個連接配接，直到連接配接狀态過期。保持連接配接有效的另一種攻擊方法是更改其他參數，例如源位址令牌，進而防止用戶端建立任何連接配接。
3.UDP放大攻擊
為了成功進行放大攻擊，攻擊者必須欺騙受害者的IP位址，并将UDP請求發送到伺服器。如果伺服器發回更重要的UDP響應，則攻擊者可以大規模利用此伺服器行為并建立DDOS攻擊情形。
具體來說，在QUIC中，當對手從目标接受位址驗證令牌并釋放最初用于生成令牌的IP位址時，就會發生UDP放大攻擊。攻擊者可以使用相同的IP位址将0-RTT連接配接發送回伺服器，該IP位址可能已被改為指向不同的端點。通過執行此設定，攻擊者可以潛在地訓示伺服器向受害伺服器發送大量流量。為了防止這種攻擊，HTTP / 3具有速率限制功能和短暫的驗證令牌，可以充當DDOS攻擊的補償控制，同時部分緩解攻擊情形。
4.流量耗盡型攻擊
當對手有意啟動多個連接配接流時，就會發生流耗盡攻擊，這可能導緻端點耗盡。攻擊者可以通過反複送出大量請求來利用窮盡序列。盡管特定的傳輸參數可能會限制并發活動流的數量，但是在某些情況下，可能會故意将伺服器配置設定為更高數值。由于伺服器的協定配置增加了協定性能，是以受害伺服器可能成為此類攻擊的目标。
5.連接配接重置攻擊
連接配接重置攻擊主要是向受害者發送無狀态重置，進而可能産生類似于TCP重置注入攻擊的拒絕服務攻擊。如果攻擊者可以獲得具有特定連接配接ID的連接配接生成的重置令牌，則可能存在潛在的攻擊媒介。最後，攻擊者可以使用生成的令牌重置具有相同連接配接ID的活動連接配接，進而使伺服器等待連接配接，直到發生逾時為止。如果大規模進行此攻擊，則伺服器必須大量消耗其資源，以等待連接配接完成。
6.QUIC版本降級攻擊
QUIC資料包保護為通信中的所有資料包（版本協商資料包除外）提供身份驗證和加密。版本協商資料包旨在協商使用者代理和伺服器之間QUIC的版本。該功能可能允許攻擊者将版本降級到QUIC的不安全版本。該攻擊目前暫時不會發生，因為隻有QUIC的一個版本，但是将來需要注意。
7.缺少監視支援
盡管一些使用者代理，伺服器和信譽良好的網站支援HTTP3 / QUIC，但是許多網絡裝置（例如反向/正向代理，負載均衡器，Web應用程式防火牆和安全事件監視工具）并不完全支援HTTP / 3。與TCP不同，QUIC連接配接中不需要套接字，這使得檢測主機和惡意連接配接變得更加困難。惡意攻擊者可能能夠通過QUIC中繼惡意有效載荷并執行資料洩露攻擊，并且保持隐身狀态，因為大多數檢測工具無法檢測到QUIC流量。關注公衆号：網際網路架構師，回複“2T”，送你一份架構師寶典。
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相比，它在資料包丢失方面做得更好，并且握手速度更快。關注公衆号：網際網路架構師，回複“2T”，送你一份架構師寶典。
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/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的重大改進。
感謝您的閱讀，也歡迎您發表關于這篇文章的任何建議，關注我，技術不迷茫！小編到你上高速。
· END ·