Geteilte DH-Gruppe, frische Geheimnisse: warum der Angriff billiger wird

Gruppenparameter sind bewusst öffentlich, und genau diese Öffentlichkeit macht sie leicht zu übersehen. Bei Diffie-Hellman über einem endlichen Körper sind Modul und Generator geteilt, die privaten Exponenten und die daraus resultierenden Sitzungsschlüssel jedoch nicht. Die teure Phase eines Angriffs mit dem Zahlkörpersieb hängt von der Gruppe ab und nicht von einer einzelnen Aushandlung, deshalb wird eine einzige schwache Gruppe, die überall verwendet wird, zu einer geteilten Last. Die Parameter öffentlich zu nennen ist zutreffend und verfehlt den Punkt, denn die Kosten, die wiederverwendet werden, sind die Kosten des Angriffs auf genau diese Gruppe.

Die öffentliche Hälfte ist nicht die verwundbare Hälfte, und darin liegt die Falle

Das übliche Halbargument besagt, die Parameter seien in einer Norm veröffentlicht, ein Angreifer kenne sie also bereits, und sie zu verbergen würde nichts ändern. Beide Aussagen sind wahr, und keine folgt aus der anderen. Eine mitgelieferte Standardgruppe ist öffentlich, und eine private Gruppe, die Sie letzte Woche erzeugt haben, ist für jeden sichtbar, der den Handshake abschließt. Geheimhaltung war nie die Kontrolle; Stärke und Validierung sind es.

Was sich ändert, ist die Zahl der Stellen, die dieselbe Schwäche teilen. Eine Organisation, die ihre eigene 2048-Bit-Gruppe erzeugt, zahlt ihre eigenen Angriffskosten, während ein von Millionen gewählter Protokollstandard eine Kostenlast auf alle amortisiert. In diesem Sinne ist eine ungewöhnliche Gruppe nicht automatisch besser. Eine ungewöhnliche Gruppe, die zu klein ist, ist schlicht ein kleineres gemeinsames Geheimnis mit weniger Augen darauf.

Validierung zählt ebenso viel wie Größe. Ein Peer, der ein Modul mit kleinen Faktoren sendet, oder eines, das nicht die vom Protokoll erwartete Form hat, kann Informationen über den privaten Exponenten preisgeben, selbst wenn die Bitlänge respektabel aussieht. Bibliotheken, die fehlerhafte Parameter schon bei der Eingabe ablehnen, leisten echte Arbeit, weshalb selbstgeschriebenes Parameter-Parsing ein schlechter Ort ist, um Aufwand zu sparen.

Was die Vorberechnung einem Angreifer tatsächlich bringt

Das Zahlkörpersieb hat eine Phase, die nur von der Primzahl abhängt, und seine Ausgabe ist gegen jede Aushandlung wiederverwendbar, die diese Primzahl verwendet. Das ist der ganze Mechanismus hinter der historischen Sorge: Der teure Teil wird einmal bezahlt, und die Grenzkosten jeder weiteren Sitzung sinken. Frische Exponenten schützen dennoch jede einzelne Aushandlung vor einem passiven Beobachter, solange die Gruppe groß genug ist, um das Sieben undurchführbar zu machen. Beide Aussagen sind vereinbar, und die meisten Debatten zu diesem Thema entstehen daraus, dass man die eine nimmt und die andere fallen lässt.

Die Logjam-Arbeit von 2015 zeigte einen Downgrade auf 512-Bit-Diffie-Hellman in Exportqualität und schätzte, was ein Angriff auf größere, breit wiederverwendete Gruppen mit erheblichen Ressourcen kosten würde. Die Demonstration war konkret, die Schätzungen waren Schätzungen, und keines von beiden war ein Beleg dafür, dass eine bestimmte VPN-Sitzung entschlüsselt wurde.

Zitieren Sie die Arbeit für den Mechanismus und für den gezeigten Downgrade, nicht als Messung Ihrer Bereitstellung. Alte Statistiken darüber, wie viele Server eine Standardgruppe teilten, beschreiben das Internet jenes Jahres, nicht ein Netz, das Sie heute prüfen können. Was sich sinnvoll übertragen lässt, ist die Frage: Verhandeln Ihre Geräte noch eine Gruppe, die klein oder schwach validiert ist?

Standardisiert ist nicht dasselbe wie schwach

RFC 7919 definiert benannte Gruppen über endlichen Körpern, damit beide Seiten sich über einen Bezeichner auf eine Gruppe einigen und eine einheitliche Politik anwenden. Standardisiert zu sein ist ein Vorteil, weil es die Mehrdeutigkeit der Aushandlung beseitigt und eine Implementierung nicht unterstützte Größen ablehnen lässt. Eine benannte Gruppe ist nur dann schwach, wenn ihre Größe unter der Politik liegt, die Sie angeblich befolgen, nicht weil sie in einem Dokument erscheint. Dieselbe Logik gilt für Gruppen elliptischer Kurven, die eine andere Struktur und andere Fehlerarten haben.

Halten Sie die Konstruktionen getrennt, wenn Sie über sie nachdenken. Eine Aussage über Diffie-Hellman über einem endlichen Körper sagt nichts über X25519, und eine Aussage über eine 1024-Bit-MODP-Gruppe sagt nichts über eine mit 3072 Bit. Stärkepolitik gilt je Mechanismus, je Größe und je Protokollversion, weshalb der Satz starke Kryptografie keine prüfbare Aussage ist.

Authentifizierung ist die andere Hälfte, und sie ersetzt nichts. Eine starke Gruppe ohne Peer-Verifikation lässt einen Angreifer in der Mitte, und ein gültiges Zertifikat kann eine 768-Bit-Aushandlung nicht retten. Prüfen Sie beides als zwei unabhängige Linien und bestätigen Sie dann, dass beide tatsächlich ausgehandelt werden.

Lesen Sie die ausgehandelte Gruppe an einer echten Verbindung ab

Lesen Sie die ausgehandelte Gruppe vom Gerät ab und nicht aus der Konfigurationsvorlage. Vorlagen beschreiben Absicht, und der interessante Wert ist der, auf den sich beide Seiten beim letzten Handshake geeinigt haben. An einem IPsec-Endpunkt gibt die Statusausgabe normalerweise den gewählten Vorschlag aus, einschließlich der MODP-Gruppe.

Erfassen Sie diese Zeile vor und nach einer Politikänderung und bewahren Sie beide im Änderungsprotokoll auf. Der Vergleich ist der Beleg.

ipsec statusall | grep -Ei "proposal|ESP|IKE"
openssl dhparam -in /etc/vpn/dh3072.pem -check -noout

Wenn der Status nach der Änderung noch die alte Gruppe zeigt, hat die Verbindung nicht neu verhandelt, und die Konfigurationsänderung hat nichts bewiesen. Starten Sie den Peer neu oder löschen Sie die Sicherheitsassoziation und lesen Sie den Status dann erneut. Eine Politik, die nur für neue Verbindungen durchgesetzt wird, lässt langlebige Tunnel so lange auf den alten Parametern, wie sie bestehen.

Prüfen Sie Gruppe und Peer-Identität getrennt

Trennen Sie, was die Gruppe schützt, davon, wer am anderen Ende sitzt. Erfassen Sie die Schlüsselaustauschmethode, die Gruppengröße und die Authentifizierungsmethode als drei Felder, denn sie versagen unabhängig voneinander. Ein Tunnel, der eine 3072-Bit-Gruppe ausgehandelt hat, aber jedes Zertifikat akzeptiert, ist nicht dasselbe Risiko wie einer, der einen Peer pinnt und eine 2048-Bit-Gruppe verwendet.

Schreiben Sie die Abnahmekriterien vor Beginn der Prüfung auf, damit das Ergebnis ein Vergleich und keine Meinung ist. Eine Mindestgruppengröße je Protokollversion, eine Positivliste benannter Gruppen und eine verpflichtende Peer-Verifikation reichen aus, um die Entscheidung mechanisch zu machen. Unklarheit in dieser Liste verwandelt eine Prüfung in eine Diskussion, und Diskussionen werden nicht behoben. Dann ist die Ausgabe eine Liste von Endpunkten, die eine festgelegte Regel verletzen.

ipsec statusall | grep -Ei "peer|auth|cert"
openssl s_client -connect vpn.acme.example:443 -brief -cipher 'DHE-RSA-AES256-GCM-SHA384'

Schließen Sie den Kreis, indem Sie die ausgehandelten Werte nach der Behebung erneut lesen. Eine regelkonforme Konfigurationsdatei ist kein Beleg dafür, dass ein Tunnel sie übernommen hat. Die Statusausgabe und ein frischer Handshake sind der Beleg, und sie zu erheben kostet weniger Zeit als das Meeting darüber, ob sie nötig sind.