SSH3 is a complete revisit of the SSH protocol, mapping its semantics on top of the HTTP mechanisms. In a nutshell, SSH3 uses QUIC+TLS1.3 for secure channel establishment and the HTTP Authorization mechanisms for user authentication. Among others, SSH3 allows the following improvements:
- Significantly faster session establishment
- New HTTP authentication methods such as OAuth 2.0 and OpenID Connect in addition to classical SSH authentication
- Robustness to port scanning attacks: your 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
SSH3 stands for the concatenation of SSH and H3.
SSH3 Is Faster
Faster for session establishment, not throughput ! SSH3 offers a significantly faster session establishment than SSHv2.
Establishing a new session with SSHv2 can take 5 to 7 network round-trip times, which can easily be noticed by the user. SSH3 only needs 3 round-trip times. The keystroke latency in a running session is unchanged.
While SSHv2 defines its own protocols for user authentication and secure channel establishment, SSH3 relies on the robust and time-tested mechanisms of TLS 1.3, QUIC and HTTP.
These protocols are already extensively used to secure security-critical applications on the Internet such as e-commerce and Internet banking.
SSH3 already implements the common password-based and public-key (RSA and EdDSA/ed25519) authentication methods.
It also supports new authentication methods such as OAuth 2.0 and allows logging in to your servers using your Google/Microsoft/Github accounts.
SSH3 Is Still Experimental
While SSH3 shows promise for faster session establishment, it is still at an early proof-of-concept stage.
As with any new complex protocol, expert cryptographic review over an extended timeframe is required before reasonable security conclusions can be made.
We are developing SSH3 as an open source project to facilitate community feedback and analysis. However, we cannot yet endorse its appropriateness for production systems without further peer review.
Please collaborate with us if you have relevant expertise!
Do Not Deploy The SSH3 Server On Your Production Servers For Now
Given the current prototype state, we advise testing SSH3 in sandboxed environments or private networks. Be aware that making experimental servers directly Internet-accessible could introduce risk before thorough security vetting.
While hiding servers behind secret paths has potential benefits, it does not negate the need for rigorous vulnerability analysis before entering production. We are excited by SSH3’s future possibilities but encourage additional scrutiny first.
Your SSH3 Public Server Can Be Hidden
Using SSH3, you can avoid the usual stress of scanning and dictionary attacks against your SSH server.
Similarly to your secret Google Drive documents, your SSH3 server can be hidden behind a secret link and only answer to authentication attempts that made an HTTP request to this specific link, like the following:
ssh3-server -bind 192.0.2.0:443 -url-path <my-long-secret>
<my-long-secret> by, let’s say, the random value
M3MzkxYWMxMjYxMjc5YzJkODZiMTAyMjU, your SSH3 server will only answer to SSH3 connection attempts made to the URL
https://192.0.2.0:443/M3MzkxYWMxMjYxMjc5YzJkODZiMTAyMjU and it will respond a
404 Not Found to other requests. Attackers and crawlers on the Internet can therefore not detect the presence of your SSH3 server.
They will only see a simple web server answering 404 status codes to every request.
For more information click here