Quelle est la différence entre SSL et SSH? Quel est le plus sûr?
Quelle est la différence entre SSH et SSL? Lequel est le plus sûr, si vous pouvez les comparer ensemble?
Lequel présente le plus de vulnérabilités potentielles?
SSL et SSH fournissent tous deux les éléments cryptographiques pour construire un tunnel pour le transport de données confidentielles avec une intégrité vérifiée. Pour cette partie, ils utilisent des techniques similaires et peuvent souffrir du même type d'attaques, ils devraient donc fournir une sécurité similaire (c'est-à-dire une bonne sécurité) en supposant qu'ils sont tous deux correctement mis en œuvre. Que les deux existent est une sorte de syndrome NIH : les développeurs SSH devraient avoir réutilisé SSL pour la partie tunnel (le protocole SSL est suffisamment flexible pour accueillir de nombreuses variantes, y compris ne pas utiliser de certificats).
Ils diffèrent sur les choses qui sont autour du tunnel. SSL utilise traditionnellement des certificats X.509 pour annoncer les clés publiques du serveur et du client; SSH a son propre format. De plus, SSH est livré avec un ensemble de protocoles pour ce qui se passe à l'intérieur du tunnel (multiplexage de plusieurs transferts, exécution d'une authentification par mot de passe dans le tunnel, gestion des terminaux. ..) bien qu'il n'y ait rien de tel dans SSL, ou, plus précisément, lorsque de telles choses sont utilisées dans SSL, elles ne sont pas considérées comme faisant partie de SSL (par exemple, lors de l'authentification HTTP basée sur un mot de passe dans un tunnel SSL, nous dire qu'il fait partie de "HTTPS", mais cela fonctionne vraiment d'une manière similaire à ce qui se passe avec SSH).
Conceptuellement, vous pouvez prendre SSH et remplacer la partie tunnel par celle de SSL. Vous pouvez également prendre HTTPS et remplacer le truc SSL par SSH-with-data-transport et un hook pour extraire la clé publique du serveur de son certificat. Il n'y a aucune impossibilité scientifique et, si elle est effectuée correctement, la sécurité resterait la même. Cependant, il n'y a pas d'ensemble de conventions ou d'outils existants à ce sujet.
Donc, nous n'utilisons pas SSL et SSH pour les mêmes choses, mais c'est à cause des outils qui étaient historiquement fournis avec les implémentations de ces protocoles, pas en raison d'un différence liée à la sécurité. Et quiconque implémente SSL ou SSH serait bien avisé de regarder quel type d'attaques ont été tentées sur les deux protocoles.
Ce n'est pas une comparaison raisonnable à faire. SSL est une méthode générale pour protéger les données transportées sur un réseau, tandis que SSH est une application réseau pour se connecter et partager des données avec un ordinateur distant.
La protection de la couche de transport dans SSH a une capacité similaire à SSL, donc ce qui est "plus sûr" dépend de ce que votre modèle de menace spécifique demande et si les implémentations de chacune résolvent les problèmes que vous essayez de traiter.
SSH dispose alors d'une couche d'authentification utilisateur qui manque à SSL (car il n'en a pas besoin - SSL a juste besoin d'authentifier les deux interfaces de connexion que SSH peut également faire). Dans l'art UTF-8:
SSL SSH
+-------------+ +-----------------+
| Nothing | | RFC4254 | Connection multiplexing
+-------------+ +-----------------+
| Nothing | | RFC4252 | User authentication
+-------------+ +-----------------+
| RFC5246 | | RFC4253 | Encrypted data transport
+-------------+ +-----------------+
En ce qui concerne le problème contre lequel il existe plus d'attaques potentielles, il semble clair que SSH a une surface d'attaque plus grande. Mais c'est juste parce que SSH a une application entière intégrée: la surface d'attaque de SSL + quelle application que vous devez fournir ne peut pas être comparée car nous n'avons pas assez d'informations.
D'un point de vue cryptographique strict, ils fournissent tous deux un cryptage authentifié, mais de deux manières différentes.
SSH utilise ce que l'on appelle Encrypt-and-MAC, c'est-à-dire que le message chiffré est juxtaposé à un code d'authentification de message (MAC) du message clair pour ajouter de l'intégrité. Il n'est pas prouvé que cela soit toujours totalement sécurisé (même si dans des cas pratiques cela devrait suffire).
SSL utilise MAC-puis-Encrypt: un MAC est juxtaposé au texte clair, puis ils sont tous les deux cryptés. Ce n'est pas le meilleur non plus, car avec certains modes de chiffrement par blocs, certaines parties du MAC peuvent être devinables et révéler quelque chose sur le chiffrement. Cela a conduit à des vulnérabilités dans TLS 1.0 (attaque BEAST).
Ils présentent donc tous deux des faiblesses théoriques potentielles. La méthode la plus puissante est Encrypt-then-MAC (ajoutez un MAC du message chiffré), qui est implémentée, par exemple, dans IPsec ESP.
Je pense qu'il y a un aspect de cette comparaison qui a été négligé. user185 s'est approché mais n'y est pas tout à fait arrivé. Je suis d'accord que ce sont des pommes et des oranges et je ressens une meilleure comparaison de pommes à pommes pour être HTTPS et SSH. HTTPS et SSH utilisent différentes couches du modèle OSI et chiffrent donc les données à différents moments de la transmission. Ensuite, les vraies questions que l'on devrait se poser seraient de savoir quand ces données sont cryptées et non cryptées pendant la transmission. Cela révélera vos surfaces d'attaque potentielles. Avec HTTPS, une fois que le paquet est reçu par un appareil dans le réseau de destination (serveur Web, routeur de frontière, équilibreur de charge, etc.), il n'est pas chiffré et passe le reste de son voyage en texte brut. Beaucoup diront que ce n'est pas un gros problème car le trafic est interne à ce moment, mais si la charge utile contient des données sensibles, elle est stockée non chiffrée dans les fichiers journaux de chaque périphérique réseau qu'elle traverse jusqu'à ce qu'elle atteigne son destination finale. Avec SSH, généralement, le périphérique de destination est spécifié et la transmission est chiffrée jusqu'à ce qu'elle atteigne ce périphérique. Il existe des moyens de rechiffrer les données HTTPS, mais ce sont des étapes supplémentaires que la plupart oublient de prendre lors de la mise en œuvre d'une solution HTTPS dans leur environnement.
ssh est comme une clé (privée) et le verrou (public)
ssl est comme la porte et les briques.
ssl fournit un lien sécurisé entre les deux serveurs informatiques. par exemple, le vôtre et celui auquel vous vous connectez.
ssh est la façon dont l'ordinateur qui se connecte peut se vérifier et accéder.
Le problème est double, ce n'est pas seulement la force et la faiblesse du cryptage. Mais c'est la facilité et la commodité de la livraison. Du point de vue commercial, SSL/TLS est plus pratique et plus facile car il nécessite simplement un navigateur et un Cert public ou privé.
Et SSH nécessite l'application ou le client léger installé pour l'utiliser. C'est plus un problème du point de vue du client Internet et de l'assistance.
Tous les utilisateurs ne sont pas brillants, en particulier ceux qui ont des problèmes technologiques.
mes 2 cents.
SSL est une couche de protocole qui est abstraite du contenu tunnelé. SSH est une version sécurisée de Shell (SH), il n'a pas été conçu pour contenir une couche abstraite en dessous, il a été conçu spécifiquement pour transporter le trafic Shell. Ainsi, bien que les opérations de chiffrement soient utilisées dans les deux, et ces opérations de chiffrement pourraient même être les mêmes, le but et la conception globale sont donc très différents.
Gardez à l'esprit qu'il existe des différences spécifiques (comme cela a été mentionné ci-dessus), mais la plupart sinon toutes ces différences sont enracinées dans le but des différents protocoles.