Warum ein größerer OpenVPN-Schlüssel den Rekey-Timer nicht ersetzt

Die Wahl von AES-256 oder einem längeren Schlüssel sagt nichts darüber aus, wie lange dieser Schlüssel verwendet werden darf. Die Schlüsselstärke beschreibt den Algorithmus; die Rekey-Richtlinie entscheidet, wann die Sitzung neues Schlüsselmaterial ableitet. Ein Deployment kann die stärkste verfügbare Chiffre wählen und sich bei der Erneuerung trotzdem irren, weil die beiden Entscheidungen an verschiedenen Stellen getroffen werden. Wer sie verwechselt, erzeugt entweder einen unnötigen Chiffrewechsel oder eine Sitzung, die ihre Richtlinie still überlebt.

Lesen Sie die Rekey-Einstellungen, bevor Sie die Chiffre anfassen, und lesen Sie dabei beide Seiten.

Schlüsselstärke und Schlüssellebensdauer beantworten verschiedene Fragen

Chiffre und Schlüsselgröße begrenzen, wie teuer ein Angriff auf mitgeschnittenen Verkehr wäre. Das Rekey-Intervall begrenzt, wie viel Verkehr ein Schlüssel schützt und wie lange ein kompromittierter Schlüssel brauchbar bleibt. Das sind unabhängige Stellschrauben, und eine stärkere Chiffre verlängert nicht die sichere Lebensdauer einer Sitzung. Die meisten Empfehlungen, die 'AES-256 verwenden' sagen, schweigen zur Erneuerung, weil Erneuerung eine Richtlinienfrage und keine Algorithmuswahl ist.

Halten Sie beides in den Deployment-Notizen fest: was den Datenkanal schützt und was den Austausch seiner Schlüssel auslöst.

Ein Rekey hat drei Auslöser, und jede Seite kann sie auslösen

OpenVPN 2.6 dokumentiert getrennte Auslöser für die Neuverhandlung nach Bytes, Paketen und verstrichener Zeit. Der Zeitauslöser ist der, den die meisten Deployments auf dem Standardwert belassen, was bedeutet, dass ein ruhiger Tunnel trotzdem planmäßig neu verschlüsselt. Jede Seite kann den Austausch beginnen, und die Seite, die ihn nicht begonnen hat, folgt. Eine Änderung des Timers auf einer Seite legt daher nicht das Verhalten der Sitzung fest; wirksam ist der Wert der Seite, die zuerst beginnt.

Byte- und Paketauslöser zählen bei hohem Durchsatz oder kleinen Paketen, wo eine reine Zeitrichtlinie einen Schlüssel weit mehr Daten schützen ließe als beabsichtigt. Bleiben diese Zähler deaktiviert, sagen Sie das bewusst in den Notizen, statt den Standard ungeprüft zu lassen.

Ein Rekey legt den Authentifizierungsablauf offen

Eine Neuverhandlung ist ein frischer TLS-Handshake, das heißt, der Authentifizierungspfad läuft erneut. Deployments mit Einmalcodes, Hardware-Token oder einer RADIUS-Challenge erfahren das auf die harte Weise: Die erste Verbindung funktioniert, und die Sitzung stirbt eine Stunde später, wenn der zweite Handshake einen Code verlangt, der bereits verbraucht ist. auth-gen-token existiert, um diese Lücke zu überbrücken, indem der Server ein kurzlebiges Token für die Neuverhandlung ausstellt, statt eine neue interaktive Anmeldung zu verlangen.

Behandeln Sie das als Ablaufproblem, das mit dem Betreiber zu lösen ist, nicht als Beleg dafür, dass die Erneuerung abgeschaltet gehört.

Testen Sie die Erneuerung unter Last, nicht in einer Sitzung von einer Minute

Ein Abnahmetest, der sich verbindet, einmal pingt und trennt, erreicht das Rekey nie. Führen Sie eine Sitzung lange genug, um den konfigurierten Auslöser zu überschreiten, halten Sie dabei eine Übertragung am Laufen und beobachten Sie die Protokolle beider Seiten für den neuen Handshake. Testen Sie dann den Fehlerpfad: was der Client tut, wenn die Neuverhandlung nicht abgeschlossen werden kann. Ein Tunnel, der sauber abbricht, ist leichter zu diagnostizieren als einer, der weiter in eine tote Sitzung sendet.

Lesen Sie eine erfolgreiche große Übertragung nicht als Beweis für eine kryptografische Schwelle. Sie zeigt nur, dass Pfad und Zähler so viel Verkehr überstanden haben.

Dokumentieren Sie beide Entscheidungen

Der Eintrag braucht zwei Zeilen: wie Pakete geschützt werden und wann dieser Schutz ersetzt wird. Fügen Sie die Zuständigkeit für jeden Wert hinzu, denn die Chiffre kann aus einem Distributionsstandard kommen, während der Timer aus einer internen Richtlinie stammt. Ein künftiger Betreiber sollte beides nicht aus einer Konfigurationsdatei erraten müssen.

Wenn Kompatibilität eine Ausnahme erzwingt, begrenzen Sie sie auf eine Version und ein Enddatum. Eine Ausnahme, die ihren Grund überlebt, wird zur Richtlinie, von der niemand mehr weiß, dass er sie gewählt hat.