it-swarm.com.de

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

Was ist der Unterschied zwischen SSH und SSL? Welches ist sicherer, wenn Sie können sie vergleichen zusammen?
Welches hat mehr potenzielle Schwachstellen?

212
Am1rr3zA

SSL und SSH stellen beide die kryptografischen Elemente bereit, um einen Tunnel für den vertraulichen Datentransport mit überprüfter Integrität zu erstellen. Für diesen Teil verwenden sie ähnliche Techniken und können unter der gleichen Art von Angriffen leiden. Daher sollten sie eine ähnliche Sicherheit (d. H. Gute Sicherheit) bieten, vorausgesetzt, sie sind beide 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 zu berücksichtigen). einschließlich der Nichtverwendung von Zertifikaten).

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 den Tunnel inside (Multiplexen mehrerer Übertragungen, Durchführen einer kennwortbasierten Authentifizierung innerhalb des Tunnels, Terminalverwaltung ...), solange dies nicht der Fall ist in SSL, 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 Werkzeuge dafür.

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

199
Thomas Pornin

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 Kunst:

      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 in SSH eine ganze Anwendung integriert ist: Die Angriffsfläche von SSL + jede Anwendung, die Sie bereitstellen müssen kann nicht verglichen werden, da wir nicht genügend Informationen haben.

87
user185

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

SSH verwendet das sogenannte Encrypt-and-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 Sicherheitslücken in TLS 1.0 (BEAST-Angriff).

Sie haben also beide potenzielle theoretische Schwächen. Die stärkste Methode ist Encrypt-then-MAC (Hinzufügen eines MAC der verschlüsselten Nachricht), die z. B. in IPsec ESP implementiert ist.

12
Halberdier

Ich denke, es gibt einen Aspekt dieses Vergleichs, der übersehen wurde. user185 kam näher, kam aber nicht ganz dahin. Ich bin damit einverstanden, dass dies Äpfel und Orangen sind und fühle mich besser als Äpfel zu Äpfeln als HTTPS und SSH. HTTPS und SSH verwenden unterschiedliche Schichten des OSI-Modells und verschlüsseln daher die Daten zu unterschiedlichen Zeitpunkten bei der Übertragung. Dann sollten die eigentlichen Fragen lauten, wann diese Daten während der Übertragung verschlüsselt und unverschlüsselt werden. Dadurch werden Ihre potenziellen Angriffsflächen sichtbar. Bei HTTPS wird das Paket, sobald es von einem Gerät im Zielnetzwerk (Webserver, Border Router, Load Balancer usw.) empfangen wurde, unverschlüsselt und verbringt den Rest seiner Reise im Klartext. Viele würden argumentieren, dass dies keine große Sache ist, da der Datenverkehr zu diesem Zeitpunkt intern ist. Wenn die Nutzdaten jedoch vertrauliche Daten enthalten, werden sie unverschlüsselt in den Protokolldateien jedes Netzwerkgeräts gespeichert, das sie durchlaufen, bis sie zu ihren Daten gelangen Endstation. Bei SSH wird normalerweise das Zielgerät angegeben und die Übertragung wird verschlüsselt, bis es dieses Gerät erreicht. Es gibt Möglichkeiten, die HTTPS-Daten erneut zu verschlüsseln. Dies sind jedoch zusätzliche Schritte, die die meisten vergessen, wenn sie eine HTTPS-Lösung in ihrer Umgebung implementieren.

3
Sam Moore

ssh ist wie ein Schlüssel (privat) und das Schloss (öffentlich)

sSL ist wie die Tür und die Ziegel.

ssl bietet eine sichere Verbindung zwischen den beiden Computerservern. zB Ihre und die, mit der Sie sich verbinden.

mit ssh kann sich der verbindende Computer selbst verifizieren und Zugriff erhalten.

2
datsusarachris

Das Problem ist zweifach, es ist nicht nur die Stärke und Schwäche der Verschlüsselung. Aber es ist 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.

Nicht alle Benutzer sind intelligent, insbesondere die technologisch herausgeforderten.

meine 2 Cent.

0

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

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

0
Gobbly