假如 SSH 协议基于 HTTP/3 构建，会是什么样？ | SDNLAB

来自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 协议及其提供的现代机制。

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 已经提供了一套可靠的机制来执行用户身份验证，这些机制已经在银行和电子商务等敏感用例中实施和使用了多年。

重新审视 SSH 协议架构

有一些建议是考虑在 QUIC 协议上运行 SSH，但这些提议仅限于在 QUIC 流中携带经典的 SSH 机制 ( draft-bider-ssh-quic-09 )。与这些主张相反，SSH3 是在 HTTP/3 之上构建的，而不是直接在 QUIC 之上构建的，并且重新考虑了整个协议架构。

减少会话建立

由于 QUIC 使用 TLS 1.3 进行协议握手，SSH3 提供了比 SSHv2 快得多的会话建立速度。使用 SSHv2 建立新会话可能需要5到7个RTT：

1.TCP 握手；
2.密钥交换和加密算法协商；
3.切换到用户身份验证协议；
4.实际用户身份验证；
5.切换到 SSH 连接协议。

依靠QUIC和HTTP/3，这个时间可以显着减少。SSH3 可以通过以下步骤建立会话：

1.QUIC 握手，包括密钥交换（在单次往返中包含了SSHv2 的步骤 1 和 2）。
2.等待 ENABLE_CONNECT_PROTOCOL HTTP 设置帧。
3.发送带有授权标头集的 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 的会话建立时间。运行的三个命令平均具有不同的输出大小：df为 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端口转发和连接迁移新的功能。

SDNLAB公众号后台回复20240220，即可获取论文下载连接

原文链接：
https://blog.apnic.net/2024/02/02/towards-ssh3-how-http-3-improves-secure-shells/