基于HTTP/3構建SSH協議會是什么樣呢？

來自UCLouvain的Fran?ois Michel 和Olivier Bonaventure在研究中思考了一個問題：如果使用最新的網絡技術來重新設計SSH協議，那新協議會是什么樣子呢？

Secure Shell (SSH) 協議專為遠程登錄會話和其他網絡服務提供安全性，利用 SSH 協議可以有效防止遠程管理過程中的信息泄露問題。SSH 構建在未加密的 TCP 協議之上，提出了自己的機制來建立安全通道并執行用戶身份驗證。

近年來，傳輸協議設計取得了重大進展，諸如 QUIC 等新協議提出了 TCP 的快速、安全替代方案。到 2023 年底，也就是在 SSH 協議設計出來近 30 年后，Fran?ois Michel 和Olivier Bonaventure根據 QUIC ( RFC 9000 )、TLS 1.3 ( RFC 8446 ) 和 HTTP/3 ( RFC 9114 ) 等最新協議重新審視了 SSH 協議。與 SSHv2 相比，該新協議的功能集有所增強。

2023 年 12 月，《Towards SSH3: how HTTP/3 improves secure shells》論文正式發表，該研究論文提出了 SSH 協議新迭代的候選方案——SSH3。該候選方案能否成為 SSH 的第三個版本，或是成為一個單獨名稱的獨立協議，還猶未可知，需要在IETF討論之后決定。（文末附論文下載）

簡而言之，SSH3 使用 QUIC 和 TLS1.3 來建立安全通道，并使用 HTTP 授權（RFC 9114、RFC 9110）機制進行用戶身份驗證。其中，SSH3 改進了以下方面：

更快的會話建立；

除了傳統的 SSH 用戶身份驗證之外，還包括 OAuth 2.0 ( RFC 6749 ) 和OpenID Connect (OIDC) 等 HTTP 身份驗證方法；

對端口掃描攻擊的魯棒性，可以使 SSH3 服務器對其他互聯網用戶不可見；

除了經典的 TCP 端口轉發之外，還有 UDP 端口轉發；

包含現代 QUIC 協議允許的所有功能，包括連接遷移和多路徑連接。

為了理解這些改進是如何實現的，先看一下最近標準化的 HTTP/3 協議及其提供的現代機制。

01

HTTP/3

HTTP/3 在 QUIC 之上提供了 HTTP/2 的特性，而不是傳統的 TCP 和 TLS 的經典組合。QUIC 提供無縫連接遷移，并且很快將提供多路徑通信 ( draft-ietf-quic-multipath-06 )，實現平滑的網絡切換，從而避免 TCP 連接中斷。

Extended CONNECT HTTP 擴展 ( RFC 9220 ) 允許應用程序直接使用底層 QUIC 流來發送任意協議數據。HTTP 最吸引人的地方是它對用戶身份驗證的支持。SSH 協議的關鍵部分在于會話建立，尤其是用戶身份驗證過程。HTTP 已經提供了一套可靠的機制來執行用戶身份驗證，這些機制已經在銀行和電子商務等敏感用例中實施和使用了多年。

02

重新審視 SSH 協議架構

有一些建議是考慮在 QUIC 協議上運行 SSH，但這些提議僅限于在 QUIC 流中攜帶經典的 SSH 機制 ( draft-bider-ssh-quic-09 )。與這些主張相反，SSH3 是在 HTTP/3 之上構建的，而不是直接在 QUIC 之上構建的，并且重新考慮了整個協議架構。

減少會話建立

由于 QUIC 使用 TLS 1.3 進行協議握手，SSH3 提供了比 SSHv2 快得多的會話建立速度。使用 SSHv2 建立新會話可能需要5到7個RTT：

TCP 握手；

密鑰交換和加密算法協商；

切換到用戶身份驗證協議；

實際用戶身份驗證；

切換到 SSH 連接協議。

依靠QUIC和HTTP/3，這個時間可以顯著減少。SSH3 可以通過以下步驟建立會話：

QUIC 握手，包括密鑰交換（在單次往返中包含了SSHv2 的步驟 1 和 2）。

等待 ENABLE_CONNECT_PROTOCOL HTTP 設置幀。

發送帶有授權標頭集的 HTTP CONNECT 方法（包括 SSHv2 的步驟 3、4 和 5）。

當與已知的支持基于 HTTP/3 的 SSH 的服務器通信時，可以忽略步驟 2。

SSHv2會話建立（左）、SSH3會話建立（右）

這大大減少了會話建立時間，如下圖所示，在ping時間為100毫秒的網絡環境下，將SSH3和經典的OpenSSH進行了比較。



在100ms RTT的網絡上比較SSH3和SSH

論文中還評估并比較了 OpenSSH SSHv2 實現和 SSH3 原型的會話建立時間。運行單命令非交互式 SSH 會話，并記錄建立會話、運行單個命令和退出所需的時間。運行的三個命令顯示在下圖的 x 軸上。

非交互式會話的完成時間

SSHv2 是經典的 OpenSSH 實現，而 SSHv2-nodelay 是 OpenSSH 的一個版本，研究人員對其進行了修改，以強制執行 TCP_NODELAY Linux 內核選項，進一步減少 SSHv2 的會話建立時間。運行的三個命令平均具有不同的輸出大?。篸f為 582 字節，sysctl為 35kB ， ls為 131kB 。對于每個運行命令，與 SSHv2 和 SSHv2-nodelay 相比，SSH3 大大縮短了會話完成時間。

URL復用

HTTP/3 的一個優勢是它提供了 URL 級別的多路復用，這是單獨使用 QUIC 無法實現的?？梢酝ㄟ^特定 URL 訪問 SSH3 實例。首先，它可以使 SSH3 對掃描攻擊具有魯棒性。與許多基于 TCP 的應用程序一樣，SSHv2 也會受到端口掃描攻擊。攻擊者可以通過掃描每個 TCP 端口，找到響應 SSH 會話建立的端口來輕松發現 SSH 公共服務器。一旦攻擊者發現公共 SSH 端點，他們就可以嘗試對密碼進行字典攻擊。

公共SSHv2服務器每隔幾秒鐘就會收到惡意連接嘗試

基于 HTTP/3，SSH3 服務器可以通過僅響應在 HTTP CONNECT 請求中輸入特定值的 SSH3 客戶端來避免被公開發現。在web應用程序中，像這樣將受保護的資源置于秘密鏈接后面是一種常見行為。然而，它只是對用戶身份驗證過程的補充。SSH3 原型已經允許將服務器放置在一個秘密鏈接后面。

SSH3 對于使用秘密 URL 的掃描攻擊具有魯棒性。不知道秘密 URL 的攻擊者無法區分 SSH3 服務器和經典 HTTP 服務器。服務器還可以配置為丟棄主機名不正確的 QUIC 連接嘗試。

另一個優勢是它允許 HTTP/3 代理作為 SSH3 網關，根據 CONNECT 請求中指定的 URL 路徑連接到不同的物理服務器。使用 HTTP 授權機制將用戶身份驗證材料附加到請求。這允許在 HTTP 代理后面定位大量虛擬機或容器，并通過其特定 URL 訪問它們，如下圖所示。除了 URL 之外，還可以基于 HTTP 主機名進行多路復用。

SSH3 原型目前僅允許基于主機名的多路復用，因為反向代理需要知道代理協議才能根據 URL 路徑正確轉發請求。

話雖如此，SSH3 用戶已經可以依靠服務器名稱指示 (SNI) 多路復用，將其 SSH3 服務器與傳統 HTTP/3 服務器共置在端口 443 上?；?SNI 的多路復用還允許定義虛擬主機，而無需解密 QUIC 流量，從而確保 SSH3 客戶端和服務器之間完整的端到端通信，無需充當中間機器的代理。

基于 HTTP 的身份驗證

SSH3 使用通用 HTTP 授權機制，并將用戶身份驗證資料放入 CONNECT 請求的授權標頭中。如果提供的標頭足以對用戶進行身份驗證和授予訪問權限，則服務器將響應200 OK HTTP響應。SSH3 原型實現了三種身份驗證技術：

使用基本 HTTP 方案 ( RFC 7617 ) 的基于密碼的經典身份驗證。

經典的基于公鑰的身份驗證使用Bearer HTTP方案(RFC 6750)，發送一個由用戶私鑰簽名的HTTP JWTBearer 令牌(RFC 7519)。

OIDC 身份驗證，使用 Bearer HTTP 方案。

HTTP身份驗證是靈活的，允許多種身份驗證機制

SSH3 原型原生支持 OIDC，允許用戶通過其公司的身份提供商或使用自己的 Google/Microsoft/Github/… 帳戶進行連接。

SSH3 with OIDC

未來還可以使用其他認證方案，并且可以添加新的標準化方案，而無需太多的實現工作，例如最近在簽名HTTP認證方案互聯網草案中提出的簽名方案。

考慮到HTTP/3協議棧的現代特性，該論文對SSH協議的設計進行了重新思考。SSH3通過重用TLS 1.3的安全機制和標準HTTP認證機制，降低了協議設計和實現的復雜性。與SSHv2相比，它大大減少了連接建立時間，提供了靈活的新方式來驗證用戶，還提供了諸如UDP端口轉發和連接遷移新的功能。




審核編輯：劉清