Wie deaktiviere ich SSLv3 auf einem OpenSSH-SSH-Server, um POODLE zu vermeiden?

Nach der neu entdeckten POODLE-Sicherheitsanfälligkeit möchte ich SSLv3 auf allen meinen SSH-Servern deaktivieren. Wie erreiche ich das mit OpenSSH?

— drs
quelle

Ist nicht einmal betroffen, überprüfen Sie CVE-2014-3566

— Braiam

@Braiam, ich wurde aufgefordert, diese Frage zu stellen, da der verlinkte Artikel den Benutzern empfiehlt, ihre SSH-Server vor dieser Sicherheitsanfälligkeit zu schützen.

— drs

Es war ihr Fehler. Google, das entdeckt hat, hat nichts über SSH gesagt.

— Braiam

-1, da SSH und SSL / TLS zwei völlig unterschiedliche Protokolle sind. ZDnet ist keine zuverlässige technische Quelle.

— Bortzmeyer

@bortzmeyer Während Sie technisch gesehen Recht haben, ist die Frage eigentlich gar nicht so schlecht. Und viele Leute fragen wahrscheinlich das Gleiche.

— Peterph

Dies ist kein Problem für OpenSSH, da SSL nicht verwendet wird.

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

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 das, was innerhalb des Tunnels geschieht (Multiplexen mehrerer Übertragungen, Durchführen einer kennwortbasierten Authentifizierung innerhalb des Tunnels, Terminalverwaltung ...), während es in SSL keine solche Funktion gibt, oder genauer gesagt, wann Solche Dinge werden in SSL verwendet. Sie werden nicht als Teil von SSL betrachtet. Wenn Sie beispielsweise eine kennwortbasierte HTTP-Authentifizierung in einem SSL-Tunnel durchführen, sagen wir, dass sie Teil von "HTTPS" ist, aber sie funktioniert wirklich ähnlich was passiert mit 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.

Als weiteren Beweis möchte ich Sie auf RFC 4253 verweisen , in dem das "SSH-Transportschichtprotokoll (Secure Shell") behandelt wird. Dies ist die benutzerdefinierte Transportschicht von SSH. Sie verwendet nicht dieselbe wie HTTPS / SSL.

Dieses Dokument beschreibt das SSH-Transportschichtprotokoll, das normalerweise auf TCP / IP ausgeführt wird. Das Protokoll kann als Grundlage für eine Reihe sicherer Netzwerkdienste verwendet werden. Es bietet starke Verschlüsselung, Serverauthentifizierung und Integritätsschutz. Es kann auch eine Komprimierung bereitstellen.

Zuletzt hatte diese Frage und Antwort von der Security SE-Site mit dem Titel: SSL3 "Poodle" Vulnerability Folgendes über den POODLE-Angriff zu sagen.

Auszug

Der Pudelangriff funktioniert in einem ausgewählten Klartextkontext wie BEAST und CRIME davor. Der Angreifer ist an Daten interessiert, die mit SSL geschützt werden, und er kann:

eigene Daten vor und nach dem geheimen Wert einspeisen, den er erhalten möchte;

Überprüfen, abfangen und ändern Sie die resultierenden Bytes auf dem Draht.

Das wichtigste und einzig plausible Szenario, in dem solche Bedingungen erfüllt sind, ist ein Webkontext: Der Angreifer führt einen gefälschten WLAN-Zugangspunkt aus und fügt selbst Javascript als Teil einer Webseite (HTTP, nicht HTTPS) ein, die das Opfer durchsucht. Das böse Javascript veranlasst den Browser, Anforderungen an eine HTTPS-Site (z. B. eine Bank-Website) zu senden, für die der Browser des Opfers ein Cookie hat. Der Angreifer will diesen Cookie.

Daher müssen für OpenSSH keine Maßnahmen gegen diese besondere Bedrohung ergriffen werden.

Verweise

Mehr lesen

Sicherheitsanfälligkeit in SSL3 "Pudel"

— slm
quelle