What would the SSH protocol look like if it was made today with recent network technologies? This is the question Olivier Bonaventure and I from UCLouvain asked ourselves when writing our latest research article.
The Secure Shell (SSH) protocol provides a secure way to access computers remotely over an untrusted network. SSH is currently the most popular way to access Unix-based hosts remotely. Built atop the unencrypted TCP protocol, SSH proposes its own mechanisms to establish a secure channel and perform user authentication.
In recent years, we saw significant advances in transport protocol design with new protocols such as QUIC proposing a fast and secure alternative to TCP. By the end of 2023, we revisited the SSH protocol in the light of recent protocols including QUIC (RFC 9000), TLS 1.3 (RFC 8446) and HTTP/3 (RFC 9114) almost 30 years after its initial design. The result is a protocol that provides an enhanced feature set without compromise compared to SSHv2.
In December 2023, we submitted our article to the SIGCOMM Computer Communication Review magazine, along with an implementation plan. A few days after the code release, we observed a significant amount of people posting about the project on social networks and news websites and it became the project with the fastest growth in our research lab, with the GitHub repository reaching more than 1,000 stars in less than 48 hours.
In this post, we explain the main ideas behind our work. This research paper presents a candidate for a new iteration of the SSH protocol, called SSH3. Whether this candidate will become the third version of SSH or a standalone protocol with a separate name will be decided in the future, probably after discussions at the Internet Engineering Task Force (IETF). However, in this blogpost, we refer to our work as SSH3.
Please note that we are researchers and have no affiliation other than our university. We are not related to OpenSSH either.
In a nutshell, SSH3 uses QUIC and TLS1.3 for secure channel establishment and the HTTP authorization (RFC 9114, RFC 9110) mechanisms for user authentication. Among others, SSH3 allows the following improvements:
- Faster session establishment.
- HTTP authentication methods such as OAuth 2.0 (RFC 6749) and OpenID Connect (OIDC) in addition to classical SSH user authentication.
- Robustness to port scanning attacks — an SSH3 server can be made invisible to other Internet users.
- UDP port forwarding in addition to classical TCP port forwarding.
- All the features allowed by the modern QUIC protocol, including connection migration (soon) and multipath connections.
To understand how these improvements are possible, let’s have a look at the recently standardized HTTP/3 protocol and the modern mechanisms it provides.
HTTP/3
HTTP/3 provides the features of HTTP/2 on top of QUIC instead of the classical combination of TCP and TLS. QUIC provides seamless connection migration, and soon, multipath communication (draft-ietf-quic-multipath-06), enabling smooth network handovers that would have disrupted the connection with TCP.
The Extended CONNECT HTTP extension (RFC 9220) allows the application to directly use the underlying QUIC stream for sending arbitrary protocol data. The most appealing aspect of HTTP is its support for user authentication. A critical part of the SSH protocol resides in the session establishment and especially the user authentication process. HTTP already provides a solid set of mechanisms to perform user authentication that have been implemented and used for years for sensitive use cases such as banking and e-commerce.
Revisiting the SSH protocol architecture
Several initiatives have already considered running SSH over the QUIC protocol, but these propositions limit themselves to carrying classical SSH mechanisms inside QUIC streams (draft-bider-ssh-quic-09). In contrast with these propositions, SSH3 is built above HTTP/3, not directly over QUIC, and reconsiders the whole protocol architecture. This section enumerates the benefits of this architecture.
Reduced session establishment
Thanks to QUIC, that uses TLS 1.3 for its protocol handshake, SSH3 offers a significantly faster session establishment than SSHv2. Establishing a new session with SSHv2 can take five to seven network Round-Trip Times (RTT):
- The TCP handshake.
- Key exchange and cryptographic algorithm negotiation.
- Switching to the user-authentication protocol.
- Actual user authentication.
- Switching to the SSH connection protocol.
Relying on QUIC and HTTP/3, this time can be significantly reduced. Our prototype can establish a session with the following steps:
- The QUIC handshake, including key exchange (includes steps 1 and 2 of SSHv2 in a single round-trip).
- Waiting for the ENABLE_CONNECT_PROTOCOL HTTP settings frame.
- Sending an HTTP CONNECT method with the authorization header set (includes steps 3, 4, and 5 of SSHv2).
Step 2 may be ignored when communicating with a server known to support SSH over HTTP/3.
This provides a noticeably reduced session establishment as can be observed in Figure 3 comparing SSH3 and the classical OpenSSH over a network with a ping of 100 milliseconds.
In our article, we evaluated and compared session establishment times of the OpenSSH SSHv2 implementation and our SSH3 prototype. To do so, we ran single-command non-interactive SSH sessions and recorded the time taken for establishing the session, running the single command, and exiting. The three commands we run are shown on the x axis of Figure 4.
SSHv2 is the classical OpenSSH implementation, while SSHv2-nodelay is a version of OpenSSH that we modified to enforce the TCP_NODELAY Linux kernel option to further reduce the session establishment time of SSHv2. The three commands we run have different output sizes on average: 582 bytes for df, 35kB for sysctl and 131kB for ls. As Figure 4 shows, SSH3 drastically reduces the session completion time compared to SSHv2 and SSHv2-nodelay for every run command.
URL multiplexing
A benefit of HTTP/3 is that it provides multiplexing at the URL level that would not be possible using QUIC solely. SSH3 instances can be accessible through specific URLs. First, it can make SSH3 robust to scanning attacks. SSHv2 is subject to port scanning attacks like many TCP-based applications. Attackers can easily discover public SSH servers by scanning every TCP port and finding the ones answering to SSH session establishment. Once the attackers have discovered a public SSH endpoint, they can try dictionary attacks on passwords.
Based on HTTP/3, SSH3 servers can avoid being publicly discovered by only answering to SSH3 clients putting a specific value in their HTTP CONNECT request. Placing protected resources behind secret links like this is a common behaviour in web applications. It is however only complementary to the user authentication process. Our SSH3 prototype already allows placing the server behind a secret link.
Another benefit is that it allows HTTP/3 proxies to act as SSH3 gateways leading to different physical servers depending on the URL path specified in the CONNECT request. User authentication material is attached to the request using HTTP Authorization mechanisms. This allows locating numerous virtual machines or containers behind HTTP proxies and making them accessible through their specific URL, as depicted in Figure 7, with each user accessing a different physical host multiplexed on a URL path basis. Multiplexing can also be performed based on the HTTP hostname in addition to the URL.
Our SSH3 prototype currently allows multiplexing based on hostnames only, as reverse proxies need to be aware of the proxied protocol to correctly forward requests based on the URL path.
That being said, SSH3 users can already co-locate their SSH3 servers with their classical HTTP/3 servers on port 443 by relying on Server Name Indication (SNI) multiplexing. Multiplexing based on the SNI also allows defining virtual hosts without having to decrypt the QUIC traffic and therefore ensures a complete end-to-end communication between the SSH3 client and server with no proxy acting as a machine-in-the-middle.
X.509 certificates
The use of TLS certificates on web servers has been democratized thanks to the efforts of initiatives such as Let’s Encrypt. Server certificates can now be installed in a matter of seconds and provide a stronger security than classical SSHv2 host keys that require Trust on First Use (TOFU) and the user to manually check the server’s hostkey during the first connection establishment.
The HTTP protocol stack comes with a series of services and facilities to generate and manage X.509 certificates for this exact purpose of host authentication. Automatic Certificate Management Environment (ACME) is a great example of how easy it can be to generate certificates for new SSH3 hosts.
Upon first startup, the host can automatically generate a valid certificate for its domain name without manual action from the user. Host certificates for SSHv2 have been proposed and implemented in OpenSSH, but these are not X.509 certificates and can therefore not benefit from these services that are already serving millions of users. X.509 certificates can also be generated for IP addresses for hosts that do not have domain names (although there is no service providing ACME for IP-based certificates yet).
Finally, for private or personal use of SSH3, self-signed certificates can also be deployed at will, providing a security level comparable to traditional SSHv2 host keys.
HTTP-based authentication
SSH3 uses the generic HTTP authorization mechanism and puts user authentication material in the Authorization header of the CONNECT request. If the provided header suffices for authenticating and granting access to the user, the server responds with the 200 OK HTTP response. Our SSH3 prototype implements three authentication techniques.
- Classical password-based authentication using the Basic HTTP scheme (RFC 7617).
- Classical public key-based authentication using the Bearer HTTP scheme (RFC 6750), sends an HTTP JWT Bearer token (RFC 7519) signed by the user’s private key.
- OIDC authentication, using the Bearer HTTP scheme.
Our SSH3 prototype natively supports OIDC, allowing users to connect through the identity provider of their company or using their own Google / Microsoft / Github/… account.
Other authentication schemes can be used in the future and newly standardized schemes can be added without much implementation effort, such as the Signature scheme recently proposed in the Signature HTTP Authentication Scheme Internet draft.
Where to go from here
The past weeks’ activity has been quite intense and we received feedback from numerous people of diverse backgrounds. This is a strong sign of the public interest in the project. Packages are also being built for diverse Linux distributions (currently under another name than SSH3 to avoid confusion with OpenSSH). Our plan in the coming months is to discuss the project at the IETF and see how it could get into the standardization process or be coordinated with other projects such as the MASQUE proxy.
How you can take part in the project
We are researchers with no private interest to defend and make no profit in developing and maintaining the project. We want the SSH3 project to grow and evolve thanks to the community, with the help and feedback from network engineers, researchers, developers, and system administrators. We encourage you to try out the project, send feedback, contribute to the codebase, provide experimental packages for your favourite distribution, and so on.
We are also looking for thorough security analysis and feedback from security experts. The project is still at an early stage. As with any new complex protocol, expert cryptographic review over an extended timeframe is required and we cannot yet endorse its appropriateness for production systems without further peer review. Please collaborate with us if you have relevant expertise!
I am easy to reach. For any questions, suggestions, or comments, do not hesitate to send me an email or directly contact me on X or LinkedIn. Also, let me know if you have already experienced SSH shortcomings not mentioned in this blog post that you would like to see addressed in this project!
Resources
Our SSH3 prototype is publicly available. The code is accessible on our GitHub repository where you can also find the most recent prebuilt releases and updates. ‘Towards SSH3: how HTTP/3 improves secure shells’ preprint is available on arXiv.
François Michel is a PhD researcher at UCLouvain interested in networking protocols.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.
“HTTP already provides a solid set of mechanisms to perform user authentication that have been implemented and used for years for sensitive use cases such as banking and e-commerce.”
I think that’s a controversial claim to make. I suppose it is referring to X.509 client certificates? Few banks use them. OpenSSH intentionally did not use X.509 certificate authentication, and continues to refuse to accept patch sets which implement it (despite being standardized in RFC6187) – it’s massively complex and fragile, everything that’s counter to security.
SSH’s own pubkey authentication requires no CA. There are optional SSH certificates, but these are much simpler than X.509
what a nightmare. now I have to get x.509 certificate authorities involved? ssh2 already supports certificate authentication, but apparently we get ‘more secure’ by just abdicating responsibility for identity verification to the inefficient browser ca forum?
you present urls as a defense against password scanning attacks, ignoring the fact that ssh2 can already disable passwords to prevent those attacks.
none of this has been audited by security professionals and I’d bet money your ‘reduced latency’ just subjects you to over-the-wire timing attacks.
decades of development on ssh just swept into the trash because modern developers don’t know anything but the web.