OpenVPN -- reneg-sec

[sergej2018]

Moin zusammen,

ich hab ein paar openVPN-Server am laufen. Diese sind im 24/7-Betrieb installiert, die Verbindungen werden also ständig aufrecht erhalten. Es werden auch permanent Daten übertragen.
Es gibt für openVPN den config-Parameter "reneg-sec", mit dem man festlegen kann, nach wie vielen Sekunden der symmetrische Verschlüsselungs-Key erneuert werden soll.
Theoretisch sollte das die Sicherheit der Verbindung ja massiv erhöhen, da ein Angreifer maximal die Daten von z.B. einigen Minuten entschlüsseln kann.
Ich hab's mal ausprobiert: Selbst wenn man den Parameter sinnlos niedrig einstellt (z.B. auf 30 Sekunden) funktionieren die Tunnel problemlos.

Meine Frage: Bringt's das? Oder macht das ständige Neu-Aushandeln des Schlüssels die ganze Sache eher unsicherer?
Dass man AES256 im Moment nicht sinnvoll knacken kann usw. ist mir bewusst.

[sergej2018]

Moin zusammen,

die Frage ist noch aktuell... hat jemand etwas dazu zu sagen?

[TomL]

Was erwartest Du denn nach Ablauf der Zeit zu sehen? Ich würde dabei davon ausgehen, dass eine laufende Verbindung nicht unterbrochen wird, sondern einfach nur im laufenden Betrieb ein neuer Schlüssel ausgehandelt wird. Es wäre ja eigentlich kontraproduktiv, wenn eine laufende Verbindung geschlossen wird... wäre der Auth-Vorgang zusätzlich mit einem Password gesichert, würde ja jeder maschinelle Re-Connect danach immer fehlschlagen, weil niemand da ist, der das Password eingaben kann. Der Effekt bei dieser Neuverhandlung ohne Re-Connect wäre imho, wenn jemand den Schlüssel aus dem vorherigen Zyklus (das meint nicht die gesamte Sitzung) gehackt hat, guckt er nach der Neuverhandlung erst mal wieder in die Röhre. Eine neue Verbindung braucht es dazu m.M.n. nicht.

Enthält das VPN-Log in dem infrage kommenen Zeitraum keine Einträge?

[sergej2018]

Doch, man sieht nach entsprechender Zeit, dass neu verbunden wird
Ob dabei nun WIRKLICH der Key getauscht wird, ist so ohne weiteres natürlich nicht einsehbar.

Meine Frage ist jetzt eher: Welcher Wert ist da sinnvoll?
Habe es testweise mal so eingstellt, dass nach 1GB oder 1/2h der Key gewechselt wird... aber das war jetzt mehr so aus dem Bauch heraus, um mal rumzuspielen.

[TomL]

Meine Frage ist jetzt eher: Welcher Wert ist da sinnvoll?

Hälst Du den Default-Wert von 3600 Sec. für zu hoch? In dem Fall würde ich auf eine halbe Stunde verkürzen, also 1800 Sec. Oder willst Du jetzt im Test nur generell bestätigen, dass der Schlüssel neu verhandelt wird?

Ich würde dazu auf dem Server mal Testweise

Code: Alles auswählen

reneg-sec 60
tran-window 60

einstellen. Und auf dem Client

Code: Alles auswählen

reneg-sec 0
tran-window 0

Nach dem Restart Openvpn würde ich jetzt erwarten, dass der Schlüssel vom Server ausgehend initiiert alle 60 Sekunden neu verhandelt wird und dann auch verwendet wird. Kannst Du bei Dir ein anderes Verhalten beobachten?

[sergej2018]

reneg-sec und tran-window sitzen schon genau so, wie du es vorgeschlagen hast

Innerhalb von 3600s (=1h) werden in meinem Tunnel halt ziemlich viel Daten übertragen und folglich mit dem selben Key verschlüsselt.
Das würd' ich eben gern ändern, indem der verwendete Key öfter gewechselt wird.

[TomL]

reneg-sec und tran-window sitzen schon genau so, wie du es vorgeschlagen hast

Ist das Verhalten resp. Log-Einträge anders, wenn Du die Werte vertauscht...?... also die 60, 60 auf Client und 0,0 auf Server

[sergej2018]

Warum muss ich die Parameter eigentlich auch auf dem Client setzen?
Dachte, das steuert erstmal der Server von seiner Seite.

Muss ich morgen mal ausprobieren...

[TomL]

Warum muss ich die Parameter eigentlich auch auf dem Client setzen?

Nein, nicht auch, sondern zum Testen nur auf dem Client. Es geht nur darum, festzustellen, ob das Verhalten dann anders ist.

[sergej2018]

Alles klar, war schon verwundert

[TomL]

Auch an diesem Ergebnis bin ich sehr interessiert... leider kann ich das hier im Moment nicht testen, weil ich auf meinem Smartphone kein Web-Guthaben eingerichtet habe und mir deswegen die Tehtering-Funktion nicht zur Verfügung steht.