AES-256 und OFB beantworten unterschiedliche Fragen, und genau hier gehen Chiffre-Reviews schief, wenn man sie als konkurrierende Optionen behandelt. Das eine benennt eine Blockchiffre mit einer Schlüssellänge; das andere beschreibt, wie eine Blockchiffre für eine längere Nachricht in einen Strom verwandelt wird. Ein Runbook für die Wahl des Schutzes muss die ganze Konstruktion betrachten, einschließlich der Frage, wie der Empfänger ein verändertes Paket erkennt.

Benennen Sie die vier Teile der Konstruktion

Jede Prüfung läuft auf vier Fragen hinaus: welche Primitive und Schlüssellänge, wie Nachrichten damit verarbeitet werden, wie der Empfänger eine unbefugte Veränderung zurückweist und wie das Protokoll Eingaben, Schlüssel und deren Lebensdauer verwaltet. Eine Liste vertrauter Namen beantwortet nur die erste. Die zweite und dritte sind der Ort der eigentlichen Unterschiede, und die vierte der Ort, an dem Implementierungen still auseinanderlaufen. Stellen Sie sie in dieser Reihenfolge und schreiben Sie die Antworten auf.

OFB erscheint unter den Vertraulichkeitsmodi in der NIST-Veröffentlichung zu Blockchiffre-Modi, und Vertraulichkeit ist alles, was es bietet. Ein Protokoll, das einen Verschlüsselungsmodus mit einem separaten MAC kombiniert, muss beide korrekt zusammensetzen, und ein Algorithmusname beweist diese Zusammensetzung nicht. Deshalb kann der Modusname allein keine Bereitstellungsentscheidung treffen.

Die vierte Frage ist die, die ein Betreiber am laufenden System tatsächlich prüfen kann.

Bevorzugen Sie eine authentifizierte Konstruktion

Authentifizierte Verschlüsselung liefert Vertraulichkeit und Integrität zusammen, und AEAD-Konstruktionen schützen auch zugehörige Daten vor Veränderung, ohne sie zu verschlüsseln. Das ist eine Eigenschaft des Paketschutzes und hat nichts damit zu tun, ob sich ein Mensch erfolgreich angemeldet hat.

Die Netgate-Leitfaden zu den Kryptoeinstellungen von OpenVPN verweist für den Datenkanal auf AEAD-Optionen, darunter AES-GCM, und das ist die Art unterstützter Richtlinie, der man folgen sollte. Verwenden Sie die Optionen, die die installierte Version und die Peer-Clients unterstützen, statt eine historische Modus-Rangliste in eine neue Bereitstellung zu kopieren. Altkompatibilität, Krypto-Backends und Offload-Unterstützung begrenzen, was tatsächlich verfügbar ist.

Eine unterstützte Konstruktion schlägt eine clevere Zusammensetzung jedes Mal.

Lesen Sie das ausgehandelte Ergebnis, nicht das Angebot

Eine Chiffre in einer akzeptierten Liste sagt nichts über die aktuelle Sitzung. Lesen Sie den ausgehandelten Datakanalschutz beim Client oder am Gateway und vergleichen Sie ihn mit der Richtlinie, die Sie durchsetzen wollten. Eine Konfiguration, die für einen alten Peer noch eine Altoption führt, ist eine Kompatibilitätsentscheidung, keine Aussage über die Sitzung vor Ihnen.

openvpn --config client.conf --verb 4 2>&1 | grep -Ei 'cipher|data channel|auth'

Am Gateway ist die entsprechende Ausgabe die Sicherheitsassoziation oder die Kryptodetails der Verbindung, je nach Plattform. In beiden Fällen sind Angebot und Ergebnis verschiedene Fakten. Eine Liste mit einer Altoption für einen alten Peer bedeutet nicht, dass jede Sitzung sie nutzt, und die Sitzung, die sie nutzt, ist das, was Sie wissen mussten.

Halten Sie beide Fakten zusammen fest, mit Datum und Client-Version.

Messen Sie nur, was vergleichbar ist

Der Durchsatz hängt von der Hardware der Endpunkte, der Implementierung, der Beschleunigung, den Paketgrößen und der gewählten Konfiguration ab. Weder die Schlüssellänge noch das Wort OFB sagen Ihnen, welche Bereitstellung schneller sein wird. Deshalb ist ein Benchmark von einer anderen Seite bestenfalls ein Hinweis auf Hardware, die jemand anderes besitzt. Ihre eigenen Zahlen beginnen bei Ihren eigenen Endpunkten.

Für einen autorisierten Vergleich halten Sie Endpunkte, Arbeitslast und geforderte Richtlinie konstant und notieren den ausgehandelten Schutz samt Implementierungsversionen. Beurteilen Sie das Ergebnis dann danach, ob die Anwendung fertig wurde, wie viel sie verlor und was die Endpunkte taten, statt Kryptokosten aus einem einzelnen Geschwindigkeitstest abzuleiten. Eine unter anderen Bedingungen erzeugte Zahl ist eine Geschichte, keine Messung.

Wenn ein alter Peer die Richtlinie nicht erfüllen kann, ist das eine Kompatibilitätsentscheidung für seinen Eigentümer.

Halten Sie Integrität aus dem Handel heraus

Integritätsprüfungen abzuschalten oder einen ungeprüften Server zu akzeptieren ist keine Leistungsoptimierung und keine Kompatibilitätslösung. Es ändert die Sicherheitseigenschaft, für die die Konstruktion gewählt wurde. Dasselbe gilt für das Erweitern der akzeptierten Chiffreliste, bis ein alter Peer sich verbindet: Die Verbindung gelingt, und die Richtlinie existiert nicht mehr.

Schreiben Sie die akzeptierte Konstruktion und ihren Eigentümer ins Runbook, damit die nächste Änderung mit einer Entscheidung beginnt und nicht mit einer Vorliebe.

Was Sie wollen, ist eine Richtlinie, die beide Seiten durchsetzen können. Zu streiten, welcher Name der stärkste ist, ist ein anderes Gespräch, und es endet meist ohne Entscheidung.

Ähnliche Artikel