La première version officielle expérimentale du serveur et du client pour le protocole SSH3 est désormais disponible. Celle-ci est conçue comme une extension du protocole HTTP/3, utilisant QUIC (basé sur UDP) et TLS 1.3 pour établir un canal de communication sécurisé, ainsi que des mécanismes HTTP pour l'authentification des utilisateurs. Le projet est développé par François Michel, doctorant à l'Université catholique de Louvain (Belgique), avec la participation d'Olivier Bonaventure, professeur de la même université, connu pour son développement du sous-système Multipath TCP et du code de routage des segments IPv6 pour le noyau Linux, ainsi que co-auteur de 10 RFC et de plus de 60 brouillons de spécifications réseau. Le code de référence de l'implémentation du client et du serveur est écrit en Go et est distribué sous la licence Apache 2.0.
Le développement de SSH3 est le résultat d'une révision complète du protocole SSH, réalisée par un groupe distinct de chercheurs, indépendamment d'OpenSSH et d'autres projets qui développent des implémentations du protocole SSH classique. Dans SSH3, la sémantique du protocole SSH classique est réalisée à travers des mécanismes HTTP, ce qui permet d'implémenter certaines fonctionnalités supplémentaires et de cacher l'activité liée à SSH parmi d'autres trafics.
Lorsqu'il utilise SSH3, le serveur est indistinguable d'un serveur HTTP et accepte les requêtes sur le port réseau 443 (HTTPS), tandis que le trafic SSH3 se mélange au trafic HTTP standard, ce qui rend difficile la réalisation d'attaques liées à l'analyse de ports et à la détection de serveurs SSH pour le craquage de mots de passe. Pour compliquer la réalisation d'attaques sur serveurs SSH3, en plus de connaître l'existence d'un serveur à une adresse IP donnée, un chemin identifiant secret du serveur SSH3 peut être spécifié. Sans soumettre le bon identifiant, le serveur traitera les requêtes comme un serveur HTTPS standard et ne révélera pas la possibilité de se connecter via SSH3. Par exemple, en spécifiant l'identifiant «e6ae772cbdaafd6918865cc2ce449dae», il est possible de se connecter au serveur uniquement via l'URL «https://192.0.2.0:443/e6ae772cbdaafd6918865cc2ce449dae», et si l'identifiant est incorrect, le serveur renverra une erreur standard «404».
La fonctionnalité avancée de SSH3 mentionne la possibilité d'utiliser des certificats d'authentification X.509 et des méthodes OAuth 2.0/OpenID Connect, en plus des méthodes classiques de SSH ; le support du redirection des ports UDP via un tunnel SSH en complément de la possibilité de redirection des ports TCP (par exemple, pour le passage de QUIC, DNS et RTP) ; l'utilisation de fonctions avancées du protocole QUIC, telles que la migration de connexions sans rupture et l'établissement de connexions multipath pour répartir le trafic sur plusieurs routes.
Il convient de noter une réduction significative du temps d'établissement de connexion avec SSH3. Lors de la connexion à un serveur SSH3, il ne faut effectuer que 3 itérations réseau (Round Trip), tandis qu'avec SSHv2, 5 à 7 itérations d'échange de paquets sont nécessaires. Le temps de réponse aux entrées du clavier pour les sessions établies dans SSH3 et SSHv2 est similaire.

Pour le chiffrement du canal de communication dans SSH3, le protocole TLS 1.3 est utilisé, tandis que les méthodes classiques basées sur des mots de passe et des clés publiques (RSA et EdDSA/ed25519) peuvent être utilisées pour l'authentification. De plus, dans SSH3, des méthodes basées sur le protocole OAuth 2.0 peuvent être appliquées, permettant de décharger l'authentification à des prestataires tiers, par exemple, pour permettre la connexion avec confirmation via des comptes dans les services Google, Microsoft et GitHub. Pour se connecter aux serveurs par clés, en plus des clés SSH, des certificats X.509 utilisés pour HTTPS peuvent être appliqués.
La mise en œuvre publiée du client et du serveur SSH3 supporte de nombreuses fonctionnalités de base d'OpenSSH, parmi lesquelles :
- Support du fichier ~/.ssh/authorized_keys avec des paramètres de clés sur le serveur.
- Possibilité d'utiliser le fichier de configuration ~/.ssh/config du côté client. Actuellement, les paramètres Hostname, User, Port et IdentityFile sont pris en charge, et les autres sont ignorés.
- Support de l'authentification de connexion au serveur basée sur des certificats.
- Support du mécanisme known_hosts (dans les situations où des certificats X.509 ne sont pas utilisés).
- Support du fonctionnement du client avec OpenSSH Agent (ssh-agent) et utilisation automatique de l'agent pour l'authentification par clés publiques.
- Support de la fonction de redirection via l'agent SSH pour utiliser des clés locales sur un serveur externe.
- Passage direct des ports TCP.
Source : opennet.ru
