来自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 的会话建立时间。运行的三个命令平均具有不同的输出大小: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端口转发和连接迁移新的功能。
审核编辑:刘清
全部0条评论
快来发表一下你的评论吧 !