Connexion SSH via HTTPS

Faire passer SSH via HTTPS

• Pour faire passer SSH via HTTPS, il faut ajuster à la fois le client et le serveur.
• Dans l’exemple de configuration côté client, les paramètres ProxyCommand et ServerAliveInterval sont définis dans le fichier ~/.ssh/config.
• Le script ~/.ssh/https-tunnel.bash utilisé crée une connexion TLS avec socat tout en envoyant la méthode CONNECT dans les en-têtes.

Exemple de configuration du serveur

• Dans la configuration du serveur HTTPS Apache2, on charge proxy_connect_module et on utilise la directive AllowCONNECT pour autoriser l’usage de la méthode HTTP CONNECT vers une cible précise.
• Côté serveur, la configuration permet d’utiliser la méthode CONNECT depuis https-server uniquement pour l’hôte cible unique ssh-server.

Contexte

• En séjournant à l’hôpital, l’auteur voulait travailler à distance via le Wi-Fi de l’hôpital, où la plupart des types de connexion étaient bloqués.
• Le réseau de l’hôpital n’autorise que les connexions HTTP et HTTPS, et SSH est totalement bloqué.
• Exploration des moyens de faire passer SSH via HTTP ou HTTPS.

Méthodes possibles

• Le projet sslh, qui permet d’héberger conjointement les protocoles SSH et HTTPS sur un seul port et de les répartir de façon transparente.
• sslh n’encapsule pas un protocole dans un autre ; il redirige vers le vrai backend à l’aide de diverses heuristiques.
• Une méthode consistant à encapsuler complètement le protocole SSH dans un autre protocole à l’aide de la directive ProxyCommand d’openssh.

SSH over HTTP

• Pour une tentative simple de SSH over HTTP, Apache2 est configuré pour autoriser la méthode CONNECT vers la cible unique ssh-server:22.
• Côté client, l’adaptation se fait facilement avec socat.
• ServerAliveInterval est utilisé pour éviter que la connexion HTTP ne soit coupée lorsqu’elle reste inactive.

SSH over HTTPS

• socat ne prend pas en charge les proxys HTTPS, mais il prend en charge l’encapsulation TLS.
• Il est facile d’implémenter manuellement une méthode basée sur CONNECT.
• Le tunnel SSH over HTTPS est mis en place à l’aide du script ~/.ssh/https-tunnel.bash.

Conclusion

• La présence quasi universelle de HTTPS permet de faire transiter des données à travers des intermédiaires très restrictifs.
• La méthode CONNECT est un hack utile pour envelopper un flux de charge utile TCP dans un flux hôte TLS.
• ServerAliveInterval sert à maintenir la connexion sur des transports sous-jacents peu adaptés aux connexions inactives.

L’avis de GN⁺

• Le point le plus important de cet article est qu’il propose une solution créative pour rendre possible une connexion SSH même dans un environnement réseau restrictif.
• La façon de combiner SSH et HTTPS peut être particulièrement intéressante pour les personnes ayant des connaissances spécialisées en sécurité réseau.
• La manière de contourner les restrictions réseau via les réglages ProxyCommand et ServerAliveInterval fournit des informations utiles aux administrateurs réseau et aux experts en sécurité.

[GN⁺]

Avis Hacker News

• Le fournisseur d’accès à Internet néerlandais XS4ALL proposait autrefois l’accès SSH via le port 80. Cette fonctionnalité était utile lorsque d’autres ports étaient bloqués, par exemple sur le Wi‑Fi d’un hôtel.
• La présence quasi universelle de HTTPS permet de faire transiter des données à travers des équipements intermédiaires très restrictifs. C’est la principale raison pour laquelle les protocoles VPN propriétaires appelés SSL VPN implémentent un mode qui démarre le tunnel via HTTPS.
• Il est aussi possible de placer SSH sur le port 80 ou 443 et d’utiliser ProxyJump via un autre hôte, ou d’obtenir une connexion Internet moins restrictive via SOCKS. Il est également possible de faire suivre le DNS via TLS vers une connexion SSH.
• Une entreprise nommée Adaptive construit une infrastructure de sécurité des données qui fournit SSH et divers protocoles via HTTP3. Cela permet aux utilisateurs de se connecter à des bases de données, des serveurs et d’autres ressources via des ports externes.
• En pratique, la plupart des pare-feu peuvent être contournés simplement en faisant écouter openssh sur le port 443.
• Il est intéressant de considérer la méthode CONNECT comme un proxy inverse plutôt que comme un proxy de transfert. Mais CONNECT seul ne suffit pas, donc SSH via WebSocket est utilisé pour contourner les proxys d’entreprise.
• La fréquence des billets sur les « nouvelles » solutions est agaçante. Ces idées ne sont pas nouvelles, et beaucoup de gens les connaissent déjà.
• Ce serait bien d’avoir dans le navigateur un système de gestion d’identité similaire à SSH. J’ai été enthousiaste la première fois que j’ai lu la proposition d’authentification HTTP à clé publique hobo, avant de découvrir qu’il n’existait ni implémentation serveur ni implémentation cliente (navigateur).
• Il y a environ 20 ans, j’utilisais un outil appelé corkscrew pour traverser les pare-feu d’entreprise. L’implémentation indépendante et l’explication de cet outil sont impressionnantes.
• Le tunneling via HTTP2 est un excellent choix. Il existe gRPC, un protocole RPC construit sur HTTP2. HTTP2 excelle pour envoyer et recevoir simultanément plusieurs flux de données sur une connexion TCP. Cependant, il n’est peut-être pas nécessaire d’utiliser HTTP3, car QUIC fournit déjà le multiplexage.