8192-Bit-Schlüssel blockieren den Handshake; 1024-Bit-DH wird abgelehnt

Bei einem Server hängen Clients eine Weile und verbinden sich dann neu, ein anderer lehnt Verbindungen sofort mit einer Meldung zur Schlüsselgröße ab. Sie sehen wie verschiedene Fehler aus und sind derselbe Fehler, der in entgegengesetzte Richtungen zeigt. Die Handshake-Kryptografie hat Kosten, die mit der Parametergröße wachsen, und sie hat auch eine Untergrenze, unter die moderne Bibliotheken nicht gehen. Die Größe des Materials zu bestimmen ist die Checkliste, und der erste Punkt ist zu entscheiden, welchen der beiden Fehler Sie tatsächlich haben.

Lesen Sie den Fehler, bevor Sie irgendetwas neu erzeugen

Das Timing verrät Ihnen das meiste. Ein Handshake, der mehrere Sekunden braucht und dann stirbt, bedeutet meist, dass die Berechnung die Geduld des Partners überdauert hat, was auf Parameter zeigt, die für die Hardware oder den Timeout zu groß sind. Eine sofortige Ablehnung, die eine Schlüssel- oder Gruppengröße nennt, zeigt in die andere Richtung, auf Material, das die Bibliothek überhaupt nicht annimmt.

Diese beiden brauchen entgegengesetzte Korrekturen, und hier gehen die meisten Versuche schief. 8192-Bit-Parameter auf einem Client neu zu erzeugen, der eine kleine Gruppe bereits abgelehnt hat, verschlimmert den langsamen Fall und hilft dem schnellen überhaupt nicht. Notieren Sie, welches Symptom Sie beobachtet haben, bevor Sie eine Datei anfassen.

Prüfen Sie dann, was vom Partner verlangt wird. Ein Server, der auf eine große Gruppe im endlichen Feld konfiguriert ist, zwingt jeden Client, bei jeder Neuverhandlung dieselbe CPU-Zeit zu verbrauchen, nicht nur beim Verbinden. Tritt das Problem in einem regelmäßigen Intervall statt beim Start auf, ist dieses Intervall ein starker Hinweis darauf, welche Einstellung teuer ist. Die Neuverhandlung wiederholt die gesamte Berechnung, ein Stocken, das stündlich wiederkehrt, ist also meist dieselben Kosten, erneut bezahlt.

Der langsame Fall: Material, das die Hardware nicht bezahlen kann

Die Arbeit von Diffie-Hellman und RSA wächst schnell mit der Schlüsselgröße, und all das geschieht, bevor irgendein Tunnelverkehr fließt. Auf einem kleinen Router oder einem leistungsschwachen Client kann eine ausreichend große Gruppe den Austausch über den Timeout der Gegenseite schieben, sodass die Verbindung erneut versucht oder einfach zu hängen scheint, ohne jeden Fehler.

Die Korrektur ist, auf eine Größe herunterzugehen, die jeder Partner unterstützt und jedes Gerät bequem berechnen kann. Ein RSA-Schlüssel mit 2048 Bit und eine Gruppe mit 2048 Bit bleiben eine breit kompatible Grundlinie; größer hilft nur, wenn alle Seiten zustimmen und die CPU es bei jeder Neuverhandlung bezahlen kann. Alles über dieser Grundlinie ist ein bewusster Kompromiss, kein Upgrade.

Größe ist kein Punktestand, und die größte Zahl in einer Vergleichstabelle ist nicht automatisch die richtige Wahl. Wählen Sie den kleinsten Wert, den Ihre Richtlinie zulässt und den alle Partner akzeptieren, und messen Sie dann den Handshake, statt anzunehmen, er sei besser geworden. Eine kleinere Gruppe, die trotzdem in den Timeout läuft, sagt Ihnen, dass die Größe nie die ganze Geschichte war.

Der schnelle Fall: eine Gruppe, die die Bibliothek ablehnt

Moderne OpenSSL-Builds lehnen die kleinsten Gruppen im endlichen Feld rundweg ab, und ein angehobenes Sicherheitsniveau schiebt die Untergrenze noch höher. Router-Firmware, die eine jahrzehntealte Parameterdatei mitbringt, ist die übliche Quelle, und das Symptom ist eine Verbindung, die sofort mit einer Meldung scheitert, die Gruppe oder Schlüsselgröße nennt. Nichts an diesem Scheitern ist sporadisch, und genau das macht es leicht zu erkennen.

Ersetzen Sie die Datei, statt die Konfiguration zu bearbeiten, um die Prüfung zu überspringen. Erzeugen Sie eine aktuelle Gruppe, validieren Sie sie, und installieren Sie sie dann dort, wo der Daemon sie tatsächlich liest. Behalten Sie die alte Datei, bis sich ein Client erfolgreich mit der neuen verbunden hat:

openssl dhparam -out /etc/openvpn/ffdhe2048.pem 2048
openssl dhparam -in /etc/openvpn/ffdhe2048.pem -check -noout
ls -l /etc/openvpn/ffdhe2048.pem

Der Prüfbefehl validiert die Datei und gibt bei Erfolg nichts Nützliches aus; die Auflistung bestätigt, dass Sie die Datei ersetzt haben, die der Dienst lädt, und nicht eine veraltete Kopie daneben. Richten Sie die Konfiguration auf diesen Pfad, starten Sie den Daemon neu und bestätigen Sie, dass ein zuvor fehlschlagender Client den Handshake nun abschließt.

Setzt der Server auch ein Sicherheitsniveau oder ein Zertifikatsprofil, lesen Sie diese, bevor Sie schließen, dass die Gruppe falsch war. Ein Profil, das eine strengere Klasse verlangt, kann Material ablehnen, das die Voreinstellung akzeptiert hätte, und diese Einstellung zu entfernen ist eine engere Änderung als die Prüfung global abzuschalten.

Wählen Sie eine Größe für den Partner und die Hardware

Finden Sie heraus, was die Gegenseite verkraftet, bevor Sie etwas Exotisches erzeugen. Ein Gerät, das zu alt für eine Gruppe mit 2048 Bit ist, ist ein Gerät zum Austauschen, denn den Server auf eine schwächere Gruppe zu richten verwandelt nur eine Kompatibilitätsbeschwerde in einen Ausfall. Dauerhafte Korrekturen gehen zu neuerer Software statt zu älteren Parametern. Jede vorübergehende Ausnahme in diesem Bereich hat die Angewohnheit, die dauerhafte Konfiguration zu werden.

Wo die CPU des Servers die Grenze ist, ändern Sie den Algorithmus, statt unter die Richtlinie zu gehen. Ein Schlüsselaustausch über elliptische Kurven wie X25519 ist dramatisch billiger als eine große Gruppe im endlichen Feld und weit verbreitet, was ihn zur besseren Antwort auf eine Leistungsbeschwerde macht als ein kleineres RSA-Modul.

Was auch immer Sie wählen, testen Sie mit einer echten Verbindung und beobachten Sie, wie lange der Handshake dauert, nicht nur ob er am Ende verbindet. Eine Verbindung, die in zwölf Sekunden gelingt, hat dieselbe Ursache wie eine, die bei fünfzehn scheitert.

Halten Sie die Wahl fest, damit ein Neuaufbau sie nicht rückgängig macht

Halten Sie die Parameterdatei unter Konfigurationsverwaltung und schreiben Sie Größe, Grund und Datum daneben. Ein neu gebauter Server, der still seine eigenen Voreinstellungen erzeugt, ist der Weg, auf dem derselbe Fehler sechs Monate später zurückkehrt, ohne dass jemand die ursprüngliche Entscheidung erklären kann.

Notieren Sie dieselben Informationen neben dem Endpunkt und dem Profil, damit eine Prüfung sie nicht aus einer Dateigröße rekonstruieren muss. Wenn die nächste Verbindung stockt, ist diese Notiz der Unterschied zwischen einer Fünf-Minuten-Prüfung und einer neuen Untersuchung. Sie hindert den nächsten Ingenieur auch daran, den langsamen Fall mit einer Korrektur zu lösen, die für den schnellen gedacht war.