Mosh est-il désormais recommandé par les experts en sécurité? (2014)
Mosh existe depuis un certain temps maintenant. Bien qu'il soit prétendu être "un remplacement de SSH" par ses auteurs, mosh dépend en fait de ssh pour effectuer l'authentification initiale, après quoi une instance du binaire mosh est démarrée sur le serveur, la connexion SSH établie sur TCP est abandonnée (après avoir rempli sa fonction pour l'authentification et l'amorçage), et toutes les communications Shell et l'itinérance réseau se font désormais via un protocole mosh sur UDP, toujours avec une sorte de cryptage, mais complètement séparé de ssh.
Tout cela semble assez simple et élégant, cependant, le diable est toujours dans les détails.
Que pensent les spécialistes de la sécurité de mosh maintenant qu'il existe depuis quelques années?
De leur propre FAQ :
Q: Votre protocole de datagramme sécurisé a-t-il été audité par des experts?
R: Non. Mosh est activement utilisé et a été lu par des nerds crypto soucieux de la sécurité qui pensent que sa conception est raisonnable, mais tout nouveau protocole de datagramme devra faire ses preuves, et SSP ne fait pas exception. Nous utilisons les implémentations de référence de AES-128 et OCB, et nous accueillons vos yeux sur le code. Nous pensons que la simplicité radicale de la conception est un avantage, mais bien sûr d'autres l'ont pensé et se sont trompés.
Quelque chose à garder à l'esprit lors de l'utilisation de MOSH ... Bien que la plupart d'entre nous utilisent SSH pour établir la connexion, MOSH n'exige pas que cela fonctionne (SSH ne lance qu'un nouveau mosh-server côté serveur et renvoie deux valeurs côté client: port- # et clé symétrique 22 octets). En tant que tel, si vous mettez la main sur les deux éléments produits par le serveur, N'IMPORTE QUI peut utiliser votre connexion (c'est-à-dire, puisque cela ne dépend pas de la source de l'IP, si vous avez accès à ces deux informations, vous sont effectivement le propriétaire de la connexion).
Cela signifie qu'il y a fondamentalement quelques surfaces d'attaque à gérer.
Le protocole lui-même et le décryptant "en vol". Cela est hautement improbable pour toute personne autre que votre gouvernement, votre FAI ou quelqu'un du même café que vous. Le coût pour le faire et l'exigence d'être en ligne avec la transmission rendent cela très peu probable (mais pas complètement inconnu)
Attaquer le port UDP ouvert une fois que le serveur mosh est actif. C'est plus probable et c'est là que le protocole a besoin de plus d'investigation. Par exemple, il y a déjà eu une attaque DOS prouvée contre le système MOSH (je ne connais pas encore le détournement). Et bien sûr, si quelqu'un obtient votre clé symétrique, il peut probablement deviner le port assez facilement.
Alors, comment utiliser ce protocole avec toutes ces incertitudes? Eh bien, vous pouvez limiter via vos iptables (ou pare-feu, etc.) d'où peuvent provenir les paquets IP ou vous pouvez configurer le portage sur le port pour le "réveiller" si quelque chose se produit. Bien sûr, vous pouvez toujours le laisser seul et vous contenter du risque général d'un protocole non audité.
Personnellement, j'utilise un heurtoir de port (je sais, beaucoup de raisons pour lesquelles cela est pénible, peu sûr, problématique, etc.) pour bloquer les 60000 adresses. Étant donné que la plupart du temps mes reconnexions proviennent de la même IP (le sans fil tombe en panne, etc.), j'ai rarement besoin de "re-frapper" pour continuer ma connexion MOSH. Bien sûr, si je ferme l'ordinateur portable, quitte le café, passe au Wi-Fi du train, etc., alors je dois re-frapper pour avoir accès à mes ports MOSH.
Pour moi, le port ou le MOSH sont des risques inhérents, mais mis ensemble, ils réduisent considérablement la surface cible. MOSH atténue bon nombre des problèmes que j'ai avec les heurtoirs de port, et le heurtoir de port atténue ma connexion de sécurité non auditée.