Gibt es Sicherheitsvorteile beim Bereitstellen benutzerdefinierter SSH-DH-Gruppen auf Nur-Client-Systemen?

16

Eine empfohlene Strategie zur Abschwächung von Logjam- bezogenen Angriffen auf SSH besteht darin, benutzerdefinierte SSH-Diffie-Hellman-Gruppen zu generieren.

ssh-keygen -G moduli-2048.candidates -b 2048
ssh-keygen -T moduli-2048 -f moduli-2048.candidates

Anschließend wird die systemweite Moduli-Datei durch die Ausgabedatei ersetzt moduli-2048. ( ssh-keygen -GWird verwendet, um Kandidaten-DH-GEX-Primzahlen zu generieren und ssh-keygen -Tdie generierten Kandidaten auf Sicherheit zu testen.)

Auf SSH-Servern, auf denen sonst bekannte Gruppen verwendet würden, die sich gut für die Vorberechnung eignen, ist dies ziemlich offensichtlich eine vernünftige Vorgehensweise. Gibt es jedoch Sicherheitsvorteile bei der Bereitstellung benutzerdefinierter SSH-DH-Gruppen auf Nur-Client-Systemen? (Das heißt, Systeme, die eine Verbindung zu SSH-Servern herstellen, jedoch niemals selbst als SSH-Server fungieren.)

Ich interessiere mich hauptsächlich für Antworten zu OpenSSH unter Linux, aber auch allgemeinere Antworten wären willkommen.

ssh ssh-keys logjam ein CVn
quelle

Antworten:

18

Sie können, wenn Sie wirklich wollen, aber ich würde nicht die Mühe machen, 2048-Bit-DH-Parameter für OpenSSH neu zu generieren. Es gibt viel wichtigere Dinge, die Sie tun müssen, um SSH zu sichern, beispielsweise das Deaktivieren von schwacher Krypto .

Was ich tun würde , ist, die vorhandenen zu löschen, die weniger als 2048 Bits sind.

awk '$5 >= 2000' /etc/ssh/moduli > /etc/ssh/moduli.strong && \
mv /etc/ssh/moduli.strong /etc/ssh/moduli

Falls Sie es nicht bemerkt haben, wird OpenSSH mit einer großen Anzahl von vorgenerierten Modulen ausgeliefert, bis zu 8192 Bit. Während wir uns heute sicherlich Sorgen um 1024-Bit-Primzahlen machen, wird angenommen, dass 2048-Bit-Primzahlen auf absehbare Zeit sicher sind. Und während sich das irgendwann ändern wird, könnte es nächste Woche sein, aber es ist wahrscheinlicher, dass es noch lange dauert, bis wir Rentner werden ...

Es gibt auch dieses merkwürdige Stück in der ssh-keygenManpage:

Es ist wichtig, dass diese Datei Module mit verschiedenen Bitlängen enthält und dass beide Enden einer Verbindung gemeinsame Module haben.

Das scheint dagegen zu sprechen, vorhandene Module zu ersetzen, obwohl es nicht den eigentlichen Grund dafür liefert.

Michael Hampton
quelle
Verwandte: Diffie-Hellman mit einem unterschiedlichen Modul auf beiden Seiten in der Kryptographie . Nach meinem begrenzten Verständnis scheint es, dass Diffie-Hellman mit einer Gruppe dieser Länge im allgemeinen Fall nicht möglich ist und in einem bestimmten Fall möglicherweise nicht möglich ist , wenn es keine gemeinsam genutzten Module einer gewünschten Länge gibt. Daher ist es eine mathematische Anforderung des Diffie-Hellman-Schlüsselaustauschprotokolls, dass die beiden Endpunkte Module gemeinsam verwenden, und der Versuch, einen Diffie-Hellman-Schlüsselaustausch zwischen zwei Endpunkten ohne gemeinsame Module durchzuführen, schlägt fehl.
ein Lebenslauf vom
2
RFC 4419 [ tools.ietf.org/html/rfc4419] ermöglicht es dem Server, benutzerdefinierte DH-Parameter bereitzustellen. Der Server sendet seine Kandidatenparameter an den Client. Wenn der Client zustimmt, verwenden beide Seiten die vom Server bereitgestellten Parameter, um ein gemeinsames Geheimnis zu generieren, das als Sitzungsschlüssel verwendet wird. Es ist also völlig in Ordnung, wenn Server und Client nicht dieselben Einträge in ihrer Moduli-Datei haben.
Brian Minton
2

Die Antwort lautet: Nein. Es gibt keine Vorteile. :)

/etc/ssh/moduli Datei wird nur für die Server-Seite verwendet.

Für den SSH-Client müssen Sie sich keine Sorgen um diese Datei machen:

Sie können die Ausführung des SSH-Clients verfolgen und sicherstellen, dass diese Datei nicht geöffnet wird.

$ strace -e openat ssh user@localhost
Adi Roiban
quelle