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

Question

In Folge derdie neu entdeckte POODLE-Sicherheitslücke, ich möchte SSLv3 auf allen meinen SSH-Servern deaktivieren. Wie erreiche ich dies mit OpenSSH?

Answer 1

Für OpenSSH ist das kein Problem, da es kein SSL nutzt.

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

Sie unterscheiden sich in den Dingen, die sich um den Tunnel herum abspielen. SSL verwendet traditionell X.509-Zertifikate zur Bekanntgabe der öffentlichen Schlüssel von Server und Client; SSH hat sein eigenes Format. Außerdem verfügt SSH über eine Reihe von Protokollen für das, was innerhalb des Tunnels passiert (Multiplexen mehrerer Übertragungen, Durchführen einer kennwortbasierten Authentifizierung innerhalb des Tunnels, Terminalverwaltung ...), während dies bei SSL nicht der Fall ist, oder genauer gesagt, wenn solche Dinge bei SSL verwendet werden, werden sie nicht als Teil von SSL betrachtet (wenn beispielsweise eine kennwortbasierte HTTP-Authentifizierung in einem SSL-Tunnel durchgeführt wird, sagen wir, dass dies Teil von „HTTPS“ ist, aber es funktioniert tatsächlich ähnlich wie bei SSH).

Konzeptionell könnten Sie SSH nehmen und den Tunnelteil durch den von SSL ersetzen. Sie könnten auch HTTPS nehmen und das SSL-Ding durch SSH mit Datentransport und einen Hook ersetzen, um den öffentlichen Schlüssel des Servers aus seinem Zertifikat zu extrahieren. Es ist wissenschaftlich nicht unmöglich und wenn es richtig gemacht wird, bleibt die Sicherheit gleich. Es gibt jedoch keine weit verbreiteten Konventionen oder vorhandenen Tools dafür.

Als weiteren Beweis möchte ich Sie verweisen aufRFC 4253, in dem das „Secure Shell (SSH) Transport Layer Protocol“ besprochen wird. Dies ist SSHs eigene benutzerdefinierte Transportschicht, es wird nicht dieselbe verwendet wie HTTPS/SSL.

Dieses Dokument beschreibt das SSH-Transportschichtprotokoll, das normalerweise auf TCP/IP läuft. 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 Komprimierung bieten.

Zum Schluss noch dieses Q&A von der Security SE-Site mit dem Titel:SSL3 „Poodle“-Sicherheitslückehatte Folgendes zum POODLE-Angriff zu sagen.

Auszug

Der Poodle-Angriff funktioniert in einem Chosen-Plaintext-Kontext, wie zuvor BEAST und CRIME. Der Angreifer ist an Daten interessiert, die mit SSL geschützt sind, und er kann:

• vor und nach dem geheimen Wert, den er erhalten möchte, eigene Daten einfügen;
• Überprüfen, abfangen und ändern Sie die resultierenden Bytes auf der Leitung.

Das wichtigste und einzig plausible Szenario, in dem solche Bedingungen erfüllt sind, ist ein Webkontext: Der Angreifer betreibt einen gefälschten WLAN-Zugangspunkt und fügt sein eigenes JavaScript als Teil einer Webseite (HTTP, nicht HTTPS) ein, die das Opfer durchsucht. Das bösartige JavaScript veranlasst den Browser, Anfragen an eine HTTPS-Site (z. B. eine Bank-Website) zu senden, für die der Browser des Opfers ein Cookie hat. Der Angreifer möchte dieses Cookie haben.

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

Verweise

• Wie POODLE entstand
• Taxonomie der in SSH verfügbaren Chiffren/MACs/Kex?
• Sichere Konfiguration von in SSH verfügbaren Chiffren/MACs/Kex

Weiterführende Literatur

• SSL3 „Poodle“-Sicherheitslücke