Question:
Quelle est la différence entre SSL et SSH? Qu'est-ce qui est le plus sûr?
Am1rr3zA
2011-01-13 15:40:18 UTC
view on stackexchange narkive permalink

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?

Ce n'est pas une vraie question. Vous comparez des pommes et des oranges. Ce qui pourrait aider, c'est si vous pouviez expliquer pourquoi vous voulez savoir - car cela pourrait guider les réponses. par exemple, vous cherchez à mettre en œuvre une solution d'accès sécurisé et recherchez la solution la plus simple à sécuriser?
@Rory Je ne pense pas, car je sais qu'ils font tous les deux un travail similaire (je ne compare pas les pommes et les oranges), mais peut-être que je me trompe, alors je deviens reconnaissant si la communauté me montre mon erreur.
@Am1rr3zA, ce n'est pas tout à fait juste qu'ils font un travail similaire. Dans la pratique, SSL et SSH sont généralement utilisés à des fins différentes: SSH est le plus souvent utilisé pour la connexion à distance, SSL pour l'accès Web crypté.
@D.W. On dirait qu'ils sont parfois utilisés pour la même chose, par ex. ** SFTP ** semble être basé sur * SSH *, tandis que ** FTPS ** est basé sur * SSL *.
Si nous divisons l'utilisation significative de ces deux protocoles, oui, la question est liée à son intention. Une analogie. Lequel est le plus sécurisé? La plupart des gens feraient la débâcle des pommes oranges. IGNOREZ que l'un est de protéger l'accès à un appareil électronique et l'autre est physique et destiné à protéger les espèces. QUI EXIGE LE PLUS GRAND NIVEAU D'EFFORT ET DE TEMPS POUR RÉALISER LE COMPROMIS. C'est vraiment ce qu'il demande. Si nous répondons avec cet état d'esprit, on peut y répondre.
Dans leur propre élément, chacun a une force. Alors regardez-le simplement du point de vue du piratage. Lequel préférez-vous pirater? En outre, la question devrait être posée "Qu'est-ce qui est le plus sûr pour le but de ... XYZ" Puisqu'il a posé la question sans fournir le but, c'est là que tout le monde s'est accroché. Mon exemple avec le coffre-fort vs. l'ouverture de session montre deux objectifs différents (c'est-à-dire là où les gens déclaraient "Hé, ces deux protocoles et leur sécurité ne remplissent généralement pas la même fonction en cours d'utilisation" et c'est tout à fait correct. L'un peut encore être "plus sécurisé" que l'autre.
Huit réponses:
#1
+206
Thomas Pornin
2011-01-13 20:55:15 UTC
view on stackexchange narkive permalink

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 doivent donc fournir une sécurité similaire (c'est-à-dire une bonne sécurité) en supposant qu'ils sont tous deux correctement mis en œuvre. Le fait que les deux existent est une sorte de syndrome du NIH: les développeurs SSH auraient dû réutiliser 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 se trouvent 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, authentification par mot de passe dans le tunnel, gestion des terminaux ...) alors qu'il n'y en a pas 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, lorsque vous effectuez une authentification HTTP basée sur un mot de passe dans un tunnel SSL, nous disons que cela 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 l'élément 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 faite correctement, la sécurité resterait la même. Cependant, il n’existe pas d’ensemble répandu de conventions ou d’outils existants pour cela.

Nous n’utilisons donc pas SSL et SSH pour les mêmes choses, mais c’est à cause des outils historiquement fournis avec les implémentations de ces protocoles, pas en raison d'une différence liée à la sécurité. Et quiconque implémente SSL ou SSH serait bien avisé de regarder quels types d'attaques ont été tentés sur les deux protocoles.

Bon travail. Et en fait, comme SSH est plus facile à configurer que SSL, de nombreuses personnes acheminent http (et non https) à l'intérieur de SSH, par exemple pour faire l'administration du système à distance avec un outil d'interface graphique Web comme ebox ou webmin.
Juste pour signaler, ce n'est pas tout à fait vrai que les gars de SSH "* devraient *" avoir utilisé SSL: SSH a été conçu très spécifiquement pour avoir une petite surface d'attaque et être très sécurisé. SSHv2 n'a aucun des problèmes et des pièges de SSL / TLS, donc avec une chose plus petite qu'ils ont bien compris, avec moins de complexité, ils sont sortis avec quelque chose de bien mieux adapté à leur situation. Cela dépend à quel point vous êtes paranoïaque: SSL n'est pas inutilisable, selon l'application, mais la conception de SSH le rend acceptable dans des situations / communautés de sécurité où SSL n'est tout simplement pas fiable.
@NicholasWilson "La conception de _SSH le rend acceptable dans les situations / communautés de sécurité où SSL n'est tout simplement pas digne de confiance_" comme ...
SSL et SSH ont été développés en parallèle (tous deux sortis en 1995), il n'est donc pas clair si SSH aurait même pu utiliser SSL. Qu'il _devrait_ avoir utilisé le SSL 2.0 contemporain est également très douteux :-)
Eh bien, SSH 2.0 était une réécriture complète du protocole et est apparu vers 1999, de sorte que l'on aurait pu réutiliser SSL 3.0 ou même TLS 1.0. Mais, bien sûr, TLS _ semble_ être lié à X.509, ce qui effraie les développeurs.
@ThomasPornin, SSL est venu avant SSH?
@NicholasWilson, Wow, alors vous dites que ** la sécurité de SSH bat SSL **?Qu'en est-il de la réponse de user185 ci-dessous, qui indique l'opposé complet?
Oui, je pense que la couche de transport / chiffrement de SSH est préférable à SSL - pour les raisons que diverses personnes ont données ci-dessus (complexité excessive n ° 1 de SSL en raison du grand nombre de correctifs du protocole, pour atténuer les défauts de conception. Même jusqu'à TLS1.1 il y a des tonnes de choses qui ne sont tout simplement pas les meilleures pratiques, et SSH 2.0 a corrigé ses problèmes au fil des ans tout en conservant une conception claire. # 2 X.509 donne une énorme surface d'attache pour TLS).
user185 envoie comparer SSL au protocole d'application SSH, ce qui n'est pas vraiment juste.SSH a un modèle de protocole en couches, dont seule la couche inférieure est comparable à SSL, et le battrait n'importe quel jour en taille et en simplicité de mise en œuvre.
@NicholasWilson: Merci beaucoup pour cet aperçu.Je suis actuellement à la recherche des meilleures pratiques à utiliser pour créer quelques systèmes d'encapsulation sécurisés cryptographiquement persistants dans certains projets à long terme - l'un est un format d'archive signé (texte en clair), et l'autre est la couche de cryptage d'un protocole filaire pour une messagerie.système.Je me suis aussi longtemps demandé comment construire un remplacement ultra-rapide pour SSH en tant qu'expérience géante.Je voulais mentionner ces contextes au cas où vous auriez connaissance de bons points de départ.
TLS semble être un système extrêmement lourd avec une histoire riche et de nombreuses couches de complexité afin de fournir une rétrocompatibilité et une interopérabilité.Je pense que je n'ai pas besoin de tout cela pour créer une bonne sécurité, mais ma difficulté est d'identifier la compatibilité croisée et les éléments «bureaucratiques» tout en conservant les parties importantes de la machinerie qui contribuent à la sécurité du système.Je suppose que ce que je dis, c'est que TLS est reconnu comme "utilisez simplement TLS et tout ira bien", mais il n'y a aucune idée collective de ce que les composants de bas niveau sont également bons / sûrs / efficaces / etc.
Je suppose que ma dernière question serait, compte tenu du niveau de détail que j'essaie d'atteindre (et je n'ai pas peur d'y arriver), quels composants de SSH sont fondamentalement meilleurs que TLS?D'accord, donc SSH n'a pas X.509.Quelles sont les autres différences / avantages / inconvénients?-- Merci beaucoup pour votre temps.
Pourquoi ne pas lire les RFC - et le code source OpenSSH est également très lisible.Quelques points à surveiller: définition PRF, authentification d'hôte, construction MAC.Au lieu de créer votre propre protocole, utilisez simplement SSH.Vous pouvez simplement saisir la couche de transport OpenSSH et vous retrouver avec un code d'appel de la même complexité que l'utilisation de TLS à partir d'OpenSSL (mais un protocole filaire plus simple).
Réponse fascinante d'@ThomasPornin, comme d'habitude.Il serait intéressant de comparer / contraster les méthodes d'authentification client basées sur les clés utilisées respectivement par SSL et SSH - c'est-à-dire les certificats clients utilisés par SSL et l'authentification par clé publique utilisée par SSH.
#2
+87
user185
2011-01-13 15:58:16 UTC
view on stackexchange narkive permalink

Ce n'est pas une comparaison raisonnable à faire. SSL est une méthode générale de protection des données transportées sur un réseau, tandis que SSH est une application réseau permettant de se connecter et de partager des données avec un ordinateur distant.

La protection de la couche de transport en SSH est similaire en capacité à SSL, Donc, ce qui est "le plus sécurisé" dépend de ce que votre modèle de menace spécifique appelle et si les implémentations de chaque solution résolvent les problèmes que vous essayez de résoudre.

SSH dispose alors d'une couche d'authentification utilisateur dont SSL manque (parce qu'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 + ------------- + + ----------------- + | Rien | | RFC4254 | Multiplexage de connexion + ------------- + + ----------------- + | Rien | | RFC4252 | Authentification des utilisateurs + ------------- + + ----------------- + | RFC5246 | | RFC4253 | Transport de données chiffrées + ------------- + + ----------------- +  

Concernant le problème dont il y a plus d'attaques potentielles contre, il semble clair que SSH a une plus grande surface d'attaque. Mais c'est juste parce que SSH a toute une application intégrée: la surface d'attaque de SSL + quelle que soit l'application que vous devez fournir ne peut pas être comparée car nous n'avons pas assez d'informations.

-1 C'est une comparaison raisonnable. Vous supposez à tort qu'OP compare SSL au programme Unix [ssh (1)] (http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/slogin.1). SSH est en fait un autre protocole assurant la sécurité de la couche de transport, qui comporte des dispositions spéciales pour les shells distants et l'exécution à distance.
+1 @jpillora bien que je convienne qu'il est logique de comparer les deux, le terme SSH n'est généralement pas utilisé pour faire référence au sous-ensemble du protocole SSH qui gère la sécurité de la couche de transport qui serait directement comparable à SSL / TLS. Il est presque exclusivement utilisé en référence au protocole de couche application qui diffère de SSL / TLS de la manière décrite dans cette réponse.
@freb la façon dont ils sont référés en général ne change pas la vérité de la question. SSH est un protocole utilisé comme couche de transport pour l'utilitaire ssh. La réponse acceptée et la plus votée reflète ce fait.
@jpillora Je voulais simplement dire que je ne pense pas que le protocole de couche de transport SSH soit ce que la plupart des gens voudraient dire étant donné la formulation de la question. Cependant, étant donné la réponse qui a été acceptée comme correcte, cela a dû être ce que OP demandait.
@freb Exactement, la plupart des gens pensent que compte tenu de la formulation, il est encore plus important de corriger cette idée fausse courante.
[SSL / TLS] (http://security.stackexchange.com/a/40038/29832) contient des dispositions qui peuvent être utilisées pour [authentifier le client] (https://en.wikipedia.org/wiki/Transport_Layer_Security# Client-authenticated_TLS_handshake). Gardez à l'esprit que SSL, en soi, a été abandonné [juin 2015] (https://tools.ietf.org/html/rfc7568), au profit de TLS.
@WarrenT, Je crois qu'il parle d'authentification de ** l'utilisateur ** (le login) alors que ce que vous avez lié parle d'authentification de l'interface.
"SSH a alors une couche d'authentification utilisateur qui manque SSL" ce n'est pas vrai, vous pouvez authentifier l'utilisateur avec un certificat ou des clés publiques dans TLS
#3
+13
Halberdier
2013-05-09 21:03:42 UTC
view on stackexchange narkive permalink

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 est toujours totalement sécurisé (même si dans des cas pratiques cela devrait suffire).

SSL utilise MAC-then-Encrypt: un MAC est juxtaposé au texte clair, puis ils sont tous les deux cryptés . Ce n'est pas non plus le meilleur, 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 ont donc deux 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.

Le protocole de paquets binaires de SSH est encrypt-and-MAC où pour chaque message en clair (m), il envoie le texte chiffré E (m) ++ MAC (m) (concaténer le message crypté avec MAC), contre SSL qui fait E (m ++ MAC (m)). Cependant, SSH est bien plus que son protocole de paquets binaires (gestion des clés, client / serveur shell distant, transfert de fichiers, etc.), tandis que SSL (maintenant appelé TLS) n'est que le protocole de couche de transport utilisé dans d'autres protocoles qui ajoutent dans les fonctionnalités nécessaires (par exemple, HTTPS, FTPS, IMAPS, etc.). Voir également la comparaison d'EtM, E&M, MtE sur: http://crypto.stackexchange.com/questions/202
Tout à fait d'accord, il y a bien plus que ce que j'ai écrit; c'est ce que je voulais dire avec mon _incipit_ "d'un point de vue cryptographique strict".
BEAST n'est pas lié à MtE et est dû à connu-IV avec CBC (dans SSL3 et TLS1.0) - ce que SSH2 fait également et n'a pas corrigé, bien qu'il ait obtenu CTR comme alternative avant que lui et TLS obtiennent AEAD = GCM(TLS aussi CCM) (et les deux ChaCha / Poly) comme meilleure alternative.Les attaques basées sur le rembourrage MtE + CBC sont POODLE et Lucky13.
J'ai une solution qui rend MAC-then-Encrypt sûr pour tout chiffrement qui a une taille de sortie = taille d'entrée et aucune entrée de données faible dans le noyau de chiffrement.
cette réponse est dépassée car ce n'est pas ce que fait TLS aujourd'hui.
#4
+3
Sam Moore
2015-06-16 02:25:25 UTC
view on stackexchange narkive permalink

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 vraiment arrivé. Je suis d'accord pour dire que ce sont des pommes et des oranges et que la comparaison des pommes aux pommes est meilleure que HTTPS et SSH. HTTPS et SSH utilisent différentes couches du modèle OSI et donc chiffrent les données à différents moments de la transmission. Ensuite, les vraies questions à se poser seraient celles de savoir quand ces données sont-elles 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 du réseau de destination (serveur Web, routeur frontalier, équilibreur de charge, etc.), il n'est pas chiffré et passe le reste de son trajet en texte brut. Beaucoup diront que ce n'est pas un gros problème puisque le trafic est interne pour le moment, mais si la charge utile contient des données sensibles, elle est stockée non crypté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 crypté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.

#5
+1
datsusarachris
2015-01-19 21:17:45 UTC
view on stackexchange narkive permalink

ssh est comme une clé (privée) et la serrure (publique)

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 manière dont l'ordinateur qui se connecte peut se vérifier et accéder.

Vous n'expliquez pas du tout le commentaire «porte et briques».SSL a également des clés publiques et privées.SSL peut également être utilisé pour l'authentification client.SSH fournit également un lien sécurisé entre le client et le serveur.
#6
  0
Gobbly
2014-08-05 03:52:56 UTC
view on stackexchange narkive permalink

SSL est une couche de protocole qui est abstraite du contenu en cours de 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. Donc, bien que les opérations cryptographiques soient utilisées dans les deux, et que ces opérations cryptographiques puissent même être les mêmes, le but, et donc la conception générale, est assez différent.

Gardez à l'esprit qu'il existe des différences spécifiques (comme cela a été cité ci-dessus ), mais la plupart sinon la totalité de ces différences sont enracinées dans le but des différents protocoles.

-1 Vous supposez à tort qu'OP compare SSL au programme Unix [ssh (1)] (http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man1/slogin.1 ). SSH est en fait un autre protocole assurant la sécurité de la couche de transport, qui comporte des dispositions spéciales pour les shells distants et l'exécution à distance.
#7
-1
Stanley Hutchinson
2013-12-13 05:19:22 UTC
view on stackexchange narkive permalink

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. Donc, du point de vue commercial, SSL / TLS est plus pratique et plus simple car il ne nécessite qu'un navigateur et un certificat public ou privé.

Et SSH nécessite soit l'application soit le client léger installé pour l'utiliser. C'est davantage un problème du point de vue et de l'assistance d'un client Internet.

#8
-1
Deep
2018-01-04 21:23:11 UTC
view on stackexchange narkive permalink

Si vous recherchez vraiment SSH vs SSL (TLS), la réponse est SSH.

L'une des raisons pour lesquelles SSH l'emporte sur SSL est la façon dont il effectue l'authentification. Pour cette raison, lorsque vous utilisez FTP, utilisez le protocole SSH (SFTP) plutôt que FTPS (FTP sur SSL).

SSH est utilisé dans les réseaux d'entreprise pour:

  • fournir un accès sécurisé aux utilisateurs et des processus automatisés
  • transferts de fichiers interactifs et automatisés
  • émission de commandes à distance

source: https://www.ssh.com/ssh/protocol/#sec-Typical-uses-of-the-SSH-protocol

"Pour une raison SSH l'emporte sur SSL est la façon dont il effectue l'authentification" Avez-vous une source ou une explication pour cette assertion?
En SSH, on a deux options pour connecter le serveur.Avec l'option d'authentification basée sur la clé, il faudra d'abord générer une clé privée SSH et une clé publique au préalable.Ce qui n'est pas beaucoup de travail supplémentaire.Ceci est également considéré comme les meilleures pratiques de sécurité.SSL a tellement de version que la dernière est TLS1.2.Ce qui signifie que ce n'est pas encore aussi sûr, mais en train de s'améliorer.
TLS a également des certificats côté client.Vous n'expliquez pas pourquoi SSH "gagne".
Si vous allez copier / coller de quelque part, assurez-vous de citer votre source.
"SSL a tellement de versions" Donc, 6 versions est "tellement"?OpenSSH est sur la version 7.7."Ce qui signifie que ce n'est pas encore aussi sûr, mais en train de s'améliorer."Votre logique n'a aucun sens ici.
Je peux utiliser TLS et une API REST pour tout accomplir sur votre liste, et en fait, c'est ainsi que de nombreuses fonctions d'administration sont maintenant gérées.


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 2.0 sous laquelle il est distribué.
Loading...