Welche OpenVPN-Pakete schützt der auth-Digest?
Die Option auth deckt weniger ab, als ein Profil vermuten lässt. Prüfen Sie den Kanal, den AEAD-Fall und den Schutz des Kontrollkanals, bevor Sie eine Digest-Richtlinie festlegen.
Die meisten Debatten über OpenVPN-Digests beginnen beim falschen Paket. auth SHA256 als „akzeptiere nur Peers, die SHA256 anbieten“ zu lesen, ist das Erste, was man verlernen muss. Die Option benennt einen Digest für bestimmte Pakete, und welche Pakete das sind, hängt vom Kanal ab und davon, ob dieser Kanal AEAD ist. Arbeiten Sie die vier Fragen unten der Reihe nach durch; jede grenzt ein, was die Einstellung in Ihrer Umgebung bedeuten kann.
Benennen Sie den Kanal, den die Einstellung schützen soll
OpenVPN hat einen Kontrollkanal, der TLS-Handshake-Verkehr trägt, und einen Datenkanal, der die Tunnel-Nutzlast trägt. Der auth-Digest spielt in beiden eine Rolle, aber nicht dieselbe, und das Profil macht den Unterschied selten sichtbar. Notieren Sie, welche der beiden Sie einschränken wollen, bevor Sie eine Konfigurationsdatei anfassen.
Die Tabelle unten ist die Kurzfassung davon, wie dieselbe Option in jedem Kontext landet.
| Context | What the auth digest does |
|---|---|
| Data channel without AEAD | Selects the HMAC digest that authenticates each data packet |
| Data channel with AEAD, such as GCM | Unused for the data channel; the cipher authenticates its own packets |
| Control channel protected by tls-auth | Selects the HMAC digest for that protection, even when data is AEAD |
Prüfen Sie, ob der Datenkanal AEAD ist, bevor Sie sich darauf verlassen
Ist die ausgehandelte Datenchiffre AES-GCM oder CHACHA20-POLY1305, authentifiziert sich der Datenkanal selbst, und der separate Digest verrichtet nicht die Arbeit, die Sie sich vielleicht vorstellen. Beide sind AEAD-Konstruktionen, Integrität entsteht also durch dieselbe Operation, die die Nutzlast verschlüsselt. Das ist kein Rückschritt, bedeutet aber, dass eine als „jedes Datenpaket ist HMAC-SHA256“ begründete Richtlinie auf diesem Tunnel sachlich falsch ist. Bestätigen Sie den ausgehandelten Wert im Server-Log oder in der Statusausgabe des Clients, bevor Sie die Richtlinie umschreiben.
Prüfen Sie die tatsächlich ausgehandelte Chiffre statt der Liste im Profil, denn die Aushandlung kann bei einem anderen Mitglied der Menge landen. data-ciphers AES-256-GCM:AES-128-GCM ist eine Aushandlungsliste, und beide Einträge sind AEAD, also verbraucht keiner von ihnen den auth-Digest für den Nutzlastschutz.
Behandeln Sie den Schutz des Kontrollkanals als eigene Entscheidung
tls-auth fügt Kontrollkanalpaketen ein HMAC hinzu und nimmt seinen Digest aus der auth-Einstellung, weshalb ein AEAD-Tunnel dennoch einen sinnvollen Digest konfiguriert haben kann. tls-crypt ist eine andere Anordnung mit eigenem festen Schutz, also nehmen Sie nicht an, dass es jede tls-auth-Eigenschaft erbt. Lesen Sie die Dokumentation für den gewählten Mechanismus, statt Annahmen zwischen ihnen zu übertragen.
Beide Peers müssen sich zudem über die Anordnung und über die Schlüsselrichtung einig sein. Ein passender Digest, aber eine in der falschen Richtung verwendete Schlüsseldatei erzeugt einen Handshake, der aus Gründen scheitert, die die Digest-Einstellung nicht erklären kann.
Halten Sie auth getrennt von Chiffre-Aushandlung und Zertifikaten
Drei Einstellungen werden ständig verwechselt: der auth-Digest, die Liste der Datenchiffren und der Signaturalgorithmus des Zertifikats. Die erste zu ändern stellt kein Zertifikat neu aus, wählt nicht dessen Signatur-Digest und erzeugt keine Benutzername-Passwort-Methode. Die Protokolloptionsdefinitionen in den OpenVPN-2.6-Quellen beschreiben jede in einem eigenen Abschnitt, was eine nützliche Erinnerung ist, dass es unabhängige Stellschrauben sind.
Wenn ein Peer nach einer Digest-Änderung die Verbindung verweigert, liegt die Ursache meist in einer Abweichung bei einer der beiden anderen Einstellungen. Lesen Sie beide Seiten, bevor Sie eine davon ändern.
Schreiben Sie die Richtlinie auf und vergleichen Sie sie mit laufenden Konfigurationen
Eine Aussage auf Flottenebene sollte die erlaubten Datenkanalmodi und den gewählten Kontrollkanalschutz ausdrücklich im selben Satz nennen. Dieser Satz ist prüfbar; „wir verwenden SHA256“ ist es nicht. Vergleichen Sie ihn dann mit effektiven Server- und Clientprofilen statt mit einer Vorlage in einem Repository.
Schließen Sie ab, indem Sie festhalten, was jeder Tunnel tatsächlich ausgehandelt hat und welcher Mechanismus seine Pakete authentifiziert hat. Eine sichtbare auth-Zeile in einem Profil ist nur ein Beleg für Konfigurationsabsicht, und Absicht ist der billigste Teil der Prüfung.