I start babbling to much?
This commit is contained in:
parent
1da802be00
commit
2d17f9674b
@ -658,6 +658,7 @@ Gelingt es einem Angreifer den Kontrollkanal zu dechiffrieren, so erhält er Ken
|
||||
Die Vertraulichkeit der über den VPN-Dienst übertragenen Daten hängt demnach von der Verschlüsselung beider Kanäle ab.
|
||||
Der logische Schluss daraus ist die Verwendung der selben Chiffre zur Verschlüsselung beider Kanäle.
|
||||
|
||||
\paragraph{Statische Konfiguration kryptografischer Parameter:}
|
||||
Damit alle VPN-Sitzungen die zuvor erläuterten, kryptografischen Parametern einhalten, werden diese Parameter in Client- und Serverkonfiguration hinterlegt.
|
||||
OpenVPN unterstützt die Aushandlung der verwendeten TLS-Chiffre für den Kontrollkanal, sowie der Chiffre für den Datenkanal.
|
||||
Die für den HMAC verwendete Pseudozufallsfunktion kann zum aktuellen Zeitpunkt (04.11.2018) jedoch nicht ausgehandelt werden.
|
||||
@ -672,10 +673,22 @@ Dabei müssen alle VPN-Benutzer über die Änderung der Parameter benachrichtigt
|
||||
Die Aktualisierung der Vorlage für die OpenVPN-Clientkonfiguration ist ebenfalls notwendig.
|
||||
Der damit verbundene Arbeitsaufwand ist akzeptabel, weil alle kryptografischen Parameter für eine Laufzeit von 20 Jahren gewählt wurden, und die Eintrittswahrscheinlichkeit dieses Falls somit als gering eingeschätzt wird.
|
||||
|
||||
Es sollen Routen in Netze gepusht werden; es sollen Routen aus dem alten VPN-Dienst übernommen werden für die Aufwärtskompatibilität; IPV6-Netze sollen dann hinzugefügt werden.
|
||||
Eine alternativ mögliche, kontinuierliche Aktualisierung der kryptografischen Parameter unter Vorgabe der zur Aushandlung verfügbaren Chiffren in der Serverkonfiguration erscheint zunächst trivial:
|
||||
Eine neue, moderne Chiffre kann in der Serverkonfiguration zur Liste der erlaubten Chiffren hinzugefügt werden und wird nach einem Neustart des VPN-Servers von allen kompatiblen VPN-Clients sofort verwendet.
|
||||
|
||||
Es müssen jedoch auch nicht mehr als modern geltende Chiffren aus der Liste der erlaubten Chiffren entfernt werden.
|
||||
Das kann dazu führen, dass einzelne VPN-Benutzer mit älterer VPN-Clientsoftware nach der Deaktivierung einer alten Chiffre plötzlich keine VPN-Sitzung mehr aufbauen können.
|
||||
|
||||
Da die Aktualisierung der VPN-Clientsoftware im Einzelfall nicht unmittelbar erfolgen kann, erfordert die Deaktivierung einer Chiffre vorher eine sorgfältige Koordination mit den VPN-Benutzern.
|
||||
Aufgrund des damit verbundenen Arbeitsaufwands wird erwartet, dass insgesamt mehr neue Chiffren aktiviert werden, als alte Chiffren deaktiviert werden.
|
||||
Die Prüfung, ob alle erlaubten Chiffren noch ausreichend sicher sind, wird dadurch aufwändiger; die Wahrscheinlichkeit, dass eine unsichere Chiffre übersehen wird, steigt.
|
||||
Für einen Angreifer steigt die Angriffsfläche, da ältere VPN-Clients durch die Wahl einer älteren Chiffre von modernen Clients unterschieden werden könnten.
|
||||
Gleichzeitig können in einer VPN-Sitzung unterschiedliche Chiffren für den Schutz von Kontroll- und Datenkanal ausgehandelt werden, sodass die effektive Vertraulichkeit von der jeweils schwächeren Chiffre bestimmt wird.
|
||||
|
||||
|
||||
|
||||
\section{PKI-Server} \label{sct:plan_pki_server}
|
||||
In diesem Abschnitt wird das Konzept zur Benutzerverwaltung aus Kapitel~\ref{sct:user_concept} unter Berücksichtigung der gewählten PKI-Software EasyRSA konkretisiert.
|
||||
|
||||
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user