Dans quelle mesure un tunnel ou une connexion SSH est-il sécurisé?

J'ai souvent conseillé aux gens d'utiliser un tunnel SSH pour sécuriser leur navigation sur des WIFI ouverts ou dans d'autres situations non sécurisées.
Un ami m'a récemment demandé à quel point un tunnel SSH était sécurisé après avoir suggéré un tunnel SSH. J'ai trébuché un peu et réitéré "c'est sûr".

Même s'il était satisfait de cette réponse, cela m'a un peu embêté auquel je n'ai pas pu répondre complètement.
Donc, la question s'adresse à vous les gars:

"Quel est le niveau de sécurité d'un tunnel SSH?"

Je voudrais juste citer un peu de Wikipedia ici:

Même si un chiffrement symétrique est actuellement incassable en exploitant les faiblesses structurelles de son algorithme, il est possible de parcourir tout l'espace des clés dans ce qu'on appelle une attaque par force brute. Étant donné que les clés symétriques plus longues nécessitent exponentiellement plus de travail pour la recherche par force brute, une clé symétrique suffisamment longue rend cette ligne d'attaque peu pratique.

Avec une clé de longueur n bits, il y a 2 ⁿ clés possibles. Ce nombre croît très rapidement à mesure que n augmente. La loi de Moore suggère que la puissance de calcul double à peu près tous les 18 à 24 mois, mais même cet effet de doublement laisse les plus grandes longueurs de clé symétriques actuellement considérées comme acceptablement bien hors de portée. Le grand nombre d'opérations (2 ¹²⁸) requis pour essayer toutes les clés 128 bits possibles est largement considéré comme hors de portée des techniques informatiques numériques conventionnelles dans un avenir prévisible. Cependant, d'autres formes de technologie informatique sont prévues qui peuvent avoir une puissance de traitement supérieure à celle des ordinateurs classiques. Si un ordinateur quantique de taille appropriée capable d'exécuter l'algorithme de Grover de manière fiable devenait disponible, cela réduirait une clé de 128 bits à une sécurité de 64 bits, à peu près un équivalent DES. C'est l'une des raisons pour lesquelles AES prend en charge une longueur de clé de 256 bits. Voir la discussion sur la relation entre les longueurs de clé et les attaques informatiques quantiques au bas de cette page pour plus d'informations.

Ainsi, une clé de 128 bits aurait 340,282,366,920,938,463,463,374,607,431,768,211,456 permutations possibles. Imaginez passer par tout cela. Même un ordinateur de bureau puissant ne peut en essayer que quelques-uns par seconde.

Donc, bien qu'il soit théoriquement possible de déchiffrer en force un flux SSH, au moment où la clé a été déchiffrée par l'ordinateur le plus puissant imaginable, deux choses se seraient produites:

1. La clé aurait été modifiée par SSH
2. Nous serions tous morts et le soleil a explosé et détruit la terre.

^{<avertissement: pas un expert en cryptographie>}

SSHv2 utilise principalement les mêmes algorithmes que TLS / SSL:

• DH , récemment ECDH ou RSA pour l'échange de clés;
• RSA , DSA ou ECDSA pour l'authentification du serveur (et très souvent, l'authentification du client).
• AES pour le chiffrement symétrique (l'ensemble du flux de données est chiffré à l'aide d'une clé générée de manière aléatoire).

Tous sont largement utilisés et éprouvés pour une utilisation quotidienne.

Cependant, dans tout protocole, la sécurité dépend de savoir que vous communiquez avec le bon serveur. Dans le cas de SSH (configuration standard), la première fois que vous vous connectez au serveur, vous devez vérifier son empreinte digitale . (Ne vous contentez pas de le confirmer sans vérifier, comme beaucoup de gens le font.) La prochaine fois, la clé du serveur sera vérifiée par rapport à une copie mise en cache pour empêcher les attaques de l'homme du milieu - mais uniquement si la bonne clé a été mise en cache en premier lieu.

(En comparaison, TLS / SSL gère ce qui précède en utilisant des certificats X.509 émis par des autorités bien connues qui sont réputées pour ne pas signer de faux certificats.)

Le vrai problème de la sécurité SSH réside dans les certificats. De nombreuses entreprises donneront des clés sécurisées pour les connexions SSH, et ce n'est pas la première fois que les bases de données contenant ces clés sont piratées. Donc, la meilleure solution pour être sûr est de générer votre propre paire de clés, mais c'est un problème, et c'est pourquoi nous comptons sur ces sociétés ... Jusqu'à ce qu'elles soient piratées et que nous n'ayons pas à vérifier 340,282,366,920,938,463,463,374,607,431,768,211,456 clés mais seulement les onces dans la base de données ..