Was ist der Unterschied zwischen SSL und SSH? Welches ist sicherer?

SSL und SSH stellen beide die Kryptografie bereit Elemente zum Erstellen eines Tunnels für den vertraulichen Datentransport mit überprüfter Integrität. Für diesen Teil verwenden sie ähnliche Techniken und können unter der gleichen Art von Angriffen leiden. Daher sollten sie eine ähnliche Sicherheit (dh gute Sicherheit) bieten, vorausgesetzt, beide sind ordnungsgemäß implementiert. Dass beide existieren, ist eine Art NIH -Syndrom: Die SSH-Entwickler sollten SSL für den Tunnelteil wiederverwendet haben (das SSL-Protokoll ist flexibel genug, um viele Variationen aufzunehmen, einschließlich keine Zertifikate verwenden).

Sie unterscheiden sich in den Dingen, die sich um den Tunnel herum befinden. SSL verwendet traditionell X.509-Zertifikate zum Ansagen öffentlicher Server- und Clientschlüssel. SSH hat ein eigenes Format. Außerdem enthält SSH eine Reihe von Protokollen für innerhalb des Tunnels (Multiplexen mehrerer Übertragungen, Durchführen einer kennwortbasierten Authentifizierung innerhalb des Tunnels, Terminalverwaltung …), während es in SSL keine solche Funktion gibt oder genauer gesagt, wenn solche Dinge in SSL verwendet werden, werden sie nicht als Teil von SSL betrachtet (wenn wir beispielsweise eine kennwortbasierte HTTP-Authentifizierung in einem SSL-Tunnel durchführen, sagen wir, dass dies Teil von „HTTPS“ ist, aber Es funktioniert wirklich ähnlich wie bei SSH.

Konzeptionell könnten Sie SSH nehmen und den Tunnelteil durch den von SSL ersetzen. Sie können auch HTTPS verwenden und das SSL-Element durch SSH-mit-Datentransport und einen Hook ersetzen, um den öffentlichen Serverschlüssel aus seinem Zertifikat zu extrahieren. Es gibt keine wissenschaftliche Unmöglichkeit und bei richtiger Vorgehensweise würde die Sicherheit gleich bleiben. Es gibt jedoch keine weit verbreiteten Konventionen oder vorhandenen Tools dafür.

Wir verwenden also nicht SSL und SSH für die gleichen Dinge, aber das liegt daran, welche Tools historisch mit den Implementierungen dieser Tools geliefert wurden Protokolle, nicht aufgrund eines sicherheitsrelevanten Unterschieds. Und wer auch immer SSL oder SSH implementiert, sollte sich überlegen, welche Art von Angriffen auf beide Protokolle versucht wurden.

Kommentare

• Gute Arbeit. Da SSH einfacher einzurichten ist als SSL, tunneln viele Leute http (nicht https) in SSH, z. B. um die Remote-Systemadministration über ein Web durchzuführen GUI-Tool wie ebox oder webmin.
• Nur um darauf hinzuweisen, ‚ ist nicht ganz richtig, dass die SSH-Leute “ sollte “ SSL verwendet haben: SSH wurde sehr speziell entwickelt, um eine kleine Angriffsfläche zu haben und sehr sicher zu sein. SSHv2 hat keines der Probleme und Fallstricke in SSL / TLS, also mit einer kleineren Sache gehen, dass sie u Gut verstanden, mit weniger Komplexität, kamen sie mit etwas heraus, das viel besser zu ihrer Situation passte. Es hängt davon ab, wie paranoid Sie sind: SSL ist je nach Anwendung nicht ‚ unbrauchbar, aber das Design von SSH ‚ macht es in Situationen akzeptabel / Sicherheitsgemeinschaften, in denen SSL einfach nicht vertrauenswürdig ist.
• @NicholasWilson “ SSH ‚ Das Design macht es in Situationen / Sicherheitsgemeinschaften akzeptabel, in denen SSL einfach ist ist nicht vertrauenswürdig “ wie …
• SSL und SSH wurden parallel entwickelt (beide wurden 1995 veröffentlicht), also ob SSH überhaupt hätte SSL verwenden können ist nicht klar. Ob es das das zeitgenössische SSL 2.0 hätte verwenden sollen, ist ebenfalls sehr zweifelhaft 🙂
• Nun, SSH 2.0 war eine vollständige Neufassung des Protokolls und erschien einige Zeit um 1999, so dass man hätte SSL 3.0 oder sogar TLS 1.0 wiederverwenden können. Aber natürlich scheint TLS mit X.509 verbunden zu sein, was Entwickler abschreckt.

Dies ist kein vernünftiger Vergleich. SSL ist eine allgemeine Methode zum Schutz von Daten, die über ein Netzwerk transportiert werden, während SSH eine Netzwerkanwendung zum Anmelden und Freigeben von Daten mit einem Remotecomputer ist.

Der Transportschichtschutz in SSH ähnelt in seiner Fähigkeit SSL. Was also „sicherer“ ist, hängt davon ab, was Ihr spezifisches Bedrohungsmodell erfordert und ob die jeweiligen Implementierungen die Probleme beheben, mit denen Sie sich befassen möchten.

SSH verfügt dann über eine Benutzerauthentifizierungsschicht, die SSL fehlt (weil es nicht benötigt wird – SSL muss nur die beiden Verbindungsschnittstellen authentifizieren, die SSH auch ausführen kann). In UTF-8 art:

 SSL SSH +-------------+ +-----------------+ | Nothing | | RFC4254 | Connection multiplexing +-------------+ +-----------------+ | Nothing | | RFC4252 | User authentication +-------------+ +-----------------+ | RFC5246 | | RFC4253 | Encrypted data transport +-------------+ +-----------------+ 

In Bezug auf das Problem, gegen das es mehr potenzielle Angriffe gibt, scheint es klar zu sein, dass SSH eine größere Angriffsfläche hat. Aber das liegt nur daran, dass SSH ein Ganzes hat anwendbar Integrierte Funktion: Die Angriffsfläche von SSL +, welche Anwendung Sie auch immer bereitstellen müssen , kann nicht verglichen werden, da wir nicht über genügend Informationen verfügen.

Kommentare

• -1 Es ist ein vernünftiger Vergleich. Sie gehen fälschlicherweise davon aus, dass OP SSL mit dem Unix-Programm ssh (1) vergleicht. SSH ist eigentlich ein weiteres Protokoll, das Sicherheit auf Transportschicht bietet und besondere Bestimmungen für Remote-Shells und Remote-Ausführung enthält.
• +1 @jpillora Ich stimme zu, dass es sinnvoll ist, die beiden zu vergleichen, der Begriff SSH ist Wird normalerweise nicht verwendet, um auf die Teilmenge des SSH-Protokolls zu verweisen, die die Sicherheit der Transportschicht behandelt, die direkt mit SSL / TLS vergleichbar wäre. Es wird fast ausschließlich in Bezug auf das Anwendungsschichtprotokoll verwendet, das sich von SSL / TLS in der in dieser Antwort beschriebenen Weise unterscheidet.
• @freb wie sie ‚ Eine allgemeine Bezugnahme ändert nichts an der Wahrheit der Sache. SSH ist ein Protokoll, das als Transportschicht für das Dienstprogramm ssh verwendet wird. Die akzeptierte und am meisten gewählte Antwort spiegelt diese Tatsache wider.
• @jpillora Ich meinte lediglich, dass ich ‚ nicht denke, dass das SSH-Transportschichtprotokoll das ist, was die meisten Leute meinen würden angesichts der Formulierung der Frage. Angesichts der Antwort, die als richtig akzeptiert wurde, muss es jedoch das gewesen sein, was OP gefragt hat.
• @freb Richtig, die meisten Leute denken, dass dies angesichts der Formulierung noch wichtiger ist, dies häufig zu korrigieren Missverständnis.

Aus streng kryptografischer Sicht bieten beide eine authentifizierte Verschlüsselung, jedoch in zwei verschiedene Wege.

SSH verwendet die sogenannte Verschlüsselung und MAC, dh die verschlüsselte Nachricht wird einem Nachrichtenauthentifizierungscode (MAC) der eindeutigen Nachricht gegenübergestellt, um die Integrität zu erhöhen. Dies ist nicht immer vollständig sicher (auch wenn es in praktischen Fällen ausreichen sollte).

SSL verwendet MAC-then-Encrypt: Ein MAC wird dem Klartext gegenübergestellt, dann werden beide verschlüsselt . Dies ist auch nicht das Beste, da bei einigen Blockverschlüsselungsmodi Teile des MAC erraten werden können und etwas auf der Verschlüsselung anzeigen. Dies führte zu Schwachstellen in TLS 1.0 (BEAST-Angriff).

Beide weisen also potenzielle theoretische Schwächen auf. Die stärkste Methode ist Encrypt-then-MAC (Hinzufügen eines MAC der verschlüsselten Nachricht), die beispielsweise in IPsec ESP implementiert ist.

Kommentare

SSH ‚ ist verschlüsselt und MAC, wobei für jede Klartextnachricht (m) der Chiffretext E (m) ++ MAC (m) gesendet wird (verschlüsselt verketten) Nachricht mit MAC) im Vergleich zu SSL mit E (m ++ MAC (m)). SSH ist jedoch viel mehr als nur das Binärpaketprotokoll (Schlüsselverwaltung, Remote-Shell-Client / Server, Dateiübertragung usw.), während SSL (jetzt TLS genannt) nur das Transportschichtprotokoll ist, das in anderen hinzugefügten Protokollen verwendet wird in der notwendigen Funktionalität (zB HTTPS, FTPS, IMAPS etc.). Siehe auch Vergleich von EtM, E & M, MtE unter: crypto.stackexchange.com / question / 202
• Völlig einverstanden, es gibt viel mehr als das, was ich geschrieben habe; Das ‚ ist das, was ich mit meinem incipit “ unter einem streng kryptografischen Gesichtspunkt „.
• BEAST ist nicht mit MtE verwandt und beruht auf bekanntem IV mit CBC (in SSL3 und TLS1.0) – was SSH2 auch tut und nicht korrigiert, obwohl es CTR als Alternative bekam, bevor sowohl es als auch TLS AEAD = GCM (TLS auch CCM) (und beide ChaCha / Poly) als bessere Alternative bekamen. Die auf MtE + CBC-Padding basierenden Angriffe sind POODLE und Lucky13.
• Ich habe eine Lösung, die MAC-then-Encrypt für jede Verschlüsselung sicher macht, deren Ausgabegröße = Eingabegröße und keine schwache Dateneingabe in die Verschlüsselung erfolgt Kern.
• Diese Antwort ist veraltet, da dies nicht das ist, was TLS heute tut.

Ich denke, es gibt einen Aspekt dieses Vergleichs, der übersehen wurde. user185 kam näher, kam aber nicht ganz dahin. Ich stimme zu, dass es sich um Äpfel und Orangen handelt und dass sich Äpfel und Äpfel im Vergleich zu HTTPS und SSH besser anfühlen. HTTPS und SSH verwenden unterschiedliche Schichten des OSI-Modells und verschlüsseln daher die Daten auf unterschiedliche Weise Die eigentliche Frage, die man sich stellen sollte, ist, wann diese Daten während der Übertragung verschlüsselt und unverschlüsselt werden. Dies zeigt Ihre potenziellen Angriffsflächen auf. Mit HTTPS, sobald das Paket von einem Gerät in empfangen wurde Das Zielnetzwerk (Webserver, Border Router, Load Balancer usw.) ist unverschlüsselt und verbringt den Rest seiner Reise im Klartext. Viele würden argumentieren, dass dies keine große Sache ist, da der Datenverkehr intern ist Dieses Mal, aber wenn die Nutzdaten vertrauliche Daten enthalten, werden sie unverschlüsselt in den Protokolldateien jedes Netzwerkgeräts gespeichert, das sie durchlaufen, bis sie ihr endgültiges Ziel erreichen. Bei SSH wird normalerweise das Zielgerät angegeben und das Die Übertragung wird verschlüsselt, bis sie dieses Gerät erreicht. Es gibt Möglichkeiten, die HTTPS-Daten neu zu verschlüsseln. Dies sind jedoch zusätzliche Schritte, die die meisten vergessen, wenn sie eine HTTPS-Lösung in ihrer Umgebung implementieren.

SSL ist eine Protokollschicht, die wird vom zu tunnelnden Inhalt abstrahiert. SSH ist eine sichere Version von Shell (SH). Es wurde nicht entwickelt, um eine abstrakte Ebene darunter zu enthalten, sondern wurde speziell für den Transport von Shell-Verkehr entwickelt. Obwohl in beiden Fällen Kryptooperationen verwendet werden und diese Kryptooperationen sogar gleich sein können, ist der Zweck und das Gesamtdesign daher sehr unterschiedlich.

Beachten Sie, dass es spezifische Unterschiede gibt (wie oben erwähnt) ), aber die meisten, wenn nicht alle dieser Unterschiede beruhen auf dem Zweck der verschiedenen Protokolle.

Kommentare

• -1 Sie gehen fälschlicherweise davon aus Dieses OP vergleicht SSL mit dem Unix-Programm ssh (1) . SSH ist eigentlich ein weiteres Protokoll, das Sicherheit auf Transportschicht bietet und besondere Bestimmungen für Remote-Shells und Remote-Ausführung enthält.

Wenn Sie wirklich nach SSH vs SSL (TLS) suchen, lautet die Antwort SSH.

Ein Grund, warum SSH SSL gewinnt, ist die Art und Weise, wie die Authentifizierung durchgeführt wird. Aus diesem Grund verwenden Sie bei Verwendung von FTP das SSH-Protokoll (SFTP) anstelle von FTPS (FTP über SSL).

SSH wird in Unternehmensnetzwerken verwendet für:

• Bereitstellung eines sicheren Zugriffs für Benutzer und automatisierte Prozesse
• interaktive und automatisierte Dateiübertragungen
• Ausgabe von Remotebefehlen

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

Kommentare

• “ Aus einem Grund gewinnt SSH SSL durch die Art und Weise, wie die Authentifizierung durchgeführt wird “ Haben Sie eine Quelle oder eine Erklärung für diese Behauptung?
• In SSH gibt es zwei Möglichkeiten, den Server zu verbinden. Bei der schlüsselbasierten Authentifizierungsoption müssen Sie zunächst einen privaten und einen öffentlichen SSH-Schlüssel generieren. Welches ist nicht viel zusätzliche Arbeit. Dies gilt auch für bewährte Sicherheitspraktiken. SSL hat so viele Versionen, dass die neueste Version TLS1.2 ist.Dies bedeutet, dass ‚ noch nicht so sicher ist, aber im Begriff ist, besser zu werden.
• TLS verfügt auch über clientseitige Zertifikate. Sie erklären nicht, warum SSH “ “ gewinnt.
• Wenn Sie von irgendwoher kopieren / einfügen möchten, Stellen Sie sicher, dass Sie Ihre Quelle angeben.
• “ SSL hat so viele Versionen “ 6 Versionen sind also “ so viele „? OpenSSH ist auf Version 7.7. “ Was bedeutet, dass ‚ noch nicht so sicher ist, aber im Begriff ist, besser zu werden. “ Ihre Logik macht hier keinen Sinn.

Das Problem ist zweifach, es “ Es ist nicht nur die Stärke und Schwäche der Verschlüsselung. Es ist auch die Leichtigkeit und Bequemlichkeit der Lieferung. Aus geschäftlicher Sicht ist SSL / TLS daher bequemer und einfacher, da nur ein Browser und entweder ein öffentliches oder ein privates Zertifikat erforderlich sind.

Für SSH muss entweder die Anwendung oder der Thin Client installiert sein. Dies ist aus Sicht des Internet-Clients und des Supports eher ein Problem.