OpenVPN-Steuerpakete verfolgen: tls-auth vor TLS

Ein tls-auth-Fehler wird meist als Aushandlungsproblem gemeldet, und er war nie eines. Die HMAC wird auf dem Steuerpaket geprüft, bevor irgendeine TLS-Verarbeitung beginnt, daher erzeugt ein falscher Schlüssel oder eine falsche Richtung einen Fehler, der wie ein Zertifikatsproblem aussieht und zwei Schichten früher entschieden wird. Behandelt man den Umschlag als eigenes Objekt, wird die Diagnose kurz: Felder lesen, bestätigen, dass die Prüfung früh greift, dann die drei Dinge vergleichen, auf die sich beide Seiten einigen müssen.

Lesen Sie den Umschlag in der Reihenfolge, in der er aufgebaut wird

Ein Steuerpaket trägt eine Sitzungskennung, die optionale tls-auth-HMAC, Wiederholungs- und Quittungsinformationen sowie eine zuverlässige Nachrichtenkennung, danach folgt die Nutzlast des Nachrichtentyps. Ist die Nachricht eine Aushandlungsnachricht, ist die Nutzlast zufällig TLS-Chiffrat. Das ist die ganze Beziehung: TLS-Material reist in einer Nachricht, die der Umschlag bereits schützt. Die OpenVPN-Referenz zum Netzwerkprotokoll listet die Felder des Steuerkanals in dieser Reihenfolge auf.

Die Zuverlässigkeitsschicht wird leicht für Kryptografie gehalten. Quittungen, Neuübertragung und die Nachrichtenkennung existieren, damit Steuernachrichten über einen unzuverlässigen Transport genau einmal und in der richtigen Reihenfolge ankommen. Sie sind keine Authentifizierung, und eine korrekte Nachrichtenkennung beweist nichts darüber, wer das Paket gesendet hat.

Behalten Sie diese Gruppierung als Konzept. Sie ist kein Byte-Reihenfolge-Diagramm und reicht nicht aus, um ein Tag zu berechnen, weil die Felder, die in die HMAC eingehen, von Implementierung, Version und Modus abhängen.

Zeigen Sie, dass die Prüfung vor der Aushandlung greift

Ein Empfänger mit dem gemeinsamen Schlüssel kann die HMAC prüfen und ein gefälschtes Paket sofort verwerfen, ohne Aushandlungszustand zuzuweisen oder Arbeit mit dem öffentlichen Schlüssel zu leisten. Der Schutz deckt auch die ersten Aushandlungspakete ab, und genau deshalb zeigt sich ein falscher Schlüssel als fehlgeschlagene Verbindung und nicht als später Authentifizierungsfehler.

Erhöhen Sie die Ausführlichkeit des Daemons und beobachten Sie den Steuerkanal statt des tun-Geräts:

openvpn --config /etc/openvpn/server.conf --verb 6

Sie suchen einen HMAC-Prüffehler des Steuerkanals, der auf Paketebene gemeldet wird, vor jeder TLS-Warnung. Eine TLS-Warnung im Protokoll bedeutet, dass der Umschlag akzeptiert wurde und der Fehler nach innen gewandert ist, was eine andere Untersuchung mit einer anderen Lösung ist.

Die Richtungsbehandlung sitzt ebenfalls hier. Wird eine statische Schlüsseldatei mit tls-auth verwendet, nehmen beide Seiten entgegengesetzte Schlüsselrichtungen ein, und das Protokoll nutzt diese Aufteilung, damit ein abgefangenes Paket nicht zu seinem Absender zurückgeworfen werden kann. Eine umgedrehte Richtung lässt den Schlüssel gleich und lässt trotzdem jedes Paket scheitern. Ändern Sie jeweils eine Seite und starten Sie dann beide Daemons neu, damit das Paar zusammen geladen wird.

Stimmen Sie Schlüssel, Richtung und Digest auf beiden Seiten ab

Drei Werte müssen übereinstimmen, und nur einer davon ist die Datei. Der Inhalt des statischen Schlüssels muss auf beiden Seiten identisch sein, die Richtung muss entgegengesetzt sein, und der für die HMAC verwendete Digest muss passen. Prüfen Sie die Konfiguration, bevor Sie das Schlüsselmaterial anfassen, denn eine einzige umgedrehte Richtung erklärt mehr Fehler als eine beschädigte Datei:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

Erzeugen Sie das gemeinsame Geheimnis mit dem Werkzeug statt mit einem Editor und halten Sie die Rechte eng:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

Ältere Versionen akzeptierten eine etwas andere Optionsreihenfolge für die Schlüsselerzeugung, und für diese Versionen geschriebene Profile sind noch im Umlauf. Die erzeugte Datei ist in beiden Fällen dieselbe Art von Objekt, daher lautet die Prüfung, ob beide Seiten identische Bytes halten, nicht, welche Schreibweise sie erzeugt hat.

Verwechseln Sie tls-auth nicht mit tls-crypt. Beide schützen den Steuerkanal, aber tls-crypt verschlüsselt ihn zusätzlich und verbirgt die Aushandlung vor Beobachtern, und es ersetzt die Richtungsaufteilung durch seine eigene Schlüsselbehandlung. Ein Profil mit dem einen wird nicht mit einem Gegenüber zusammenarbeiten, das für das andere konfiguriert ist, und kein Digest-Tuning schließt diese Lücke.

Reproduzieren Sie ein Tag nur aus dem echten Format

Byte-genaue Reproduktion ist eine andere Aufgabe als der Betrieb einer VPN, und sie gelingt nur mit den echten Eingaben: der Implementierung und Version, die das Paket gebaut haben, dem gewählten Digest, der Richtung und den tatsächlichen Bytes einschließlich Sitzungskennung und Quittungsarray. Eine textliche Darstellung der Feldliste sind diese Bytes nicht.

Die Tag-Länge folgt aus dem Digest, daher bricht die Annahme einer festen Länge in dem Moment, in dem jemand sie ändert. Hashen Sie das Paket so, wie es die Implementierung tut, nicht wie es eine Tabelle in einem Blogbeitrag darstellt, und vergleichen Sie mit einem Mitschnitt vom selben Gegenüber statt mit einer von Hand abgeleiteten Erwartung.

Halten Sie diese Übung von Produktionsprofilen fern. Nichts an der Reproduktion eines Tags sagt Ihnen, ob ein Deployment den Schutz aktivieren sollte.

Machen Sie eine Abweichung rückgängig, ohne den Schutz zu entfernen

Der verführerische Test ist, tls-auth zu löschen, die Verbindung gelingen zu sehen und zu schließen, der Schlüssel sei falsch gewesen. Diese Antwort kostet Sie den Schutz und lehrt nichts darüber, welcher der drei Werte abwich. Holen Sie sich stattdessen die freigegebene passende Konfiguration von der Serverseite und vergleichen Sie damit.

Bereiten Sie die Änderung so vor, dass sie umkehrbar ist. Behalten Sie die vorherige Serverkonfiguration und Schlüsseldatei, wenden Sie das korrigierte Paar an, prüfen Sie, dass ein Client die Aushandlung abschließt, und entfernen Sie erst dann die Sicherung. Scheitern Clients nach der Änderung, stellen Sie die vorherigen Dateien wieder her, statt während einer Störung eine dritte Variante zu improvisieren. Die Wiederherstellung sollte ein Befehl sein, den Sie schon vor dem Beginn kennen.

Denken Sie schließlich daran, was eine bestandene Prüfung bedeutet. Sie beweist, dass das Gegenüber den gemeinsamen Schlüssel hält, nicht dass sein Zertifikat oder Konto autorisiert ist, und sie sagt nichts über die ausgehandelte Chiffre des Datenkanals. Autorisierung und Datenschutz werden später hergestellt, daher ist eine saubere Umschlagprüfung ein Ausgangspunkt und kein Urteil.