OpenVPN tls-crypt-v2: Was der Client-Schlüssel und der eingewickelte Blob tun

Ein tls-crypt-v2-Profil in ein Ticket einzufügen wirkt harmlos, bis man zählt, was die Datei enthält. Der Steuerschlüssel des Clients steht neben einer verschlüsselten Kopie desselben Schlüssels, und ein drittes Objekt, der Wickelschlüssel, verlässt nie den annehmenden Server. Diese drei beantworten unterschiedliche Fragen zu Verwahrung, Weitergabe und Rückzug. Ihre Trennung erledigt die meisten Richtlinienstreitigkeiten, bevor sie beginnen.

Was das Profil tatsächlich enthält

Die Client-Hälfte von tls-crypt-v2 ist ein Schlüssel plus eine eingewickelte Kopie davon. Der Client nutzt den einfachen Schlüssel zum Schutz des Steuerkanals und übergibt die eingewickelte Kopie beim Einrichten an den Server, sodass der Server denselben Schlüssel zurückgewinnt, ohne eine Klartextkopie pro Client zu speichern. Der Wickelschlüssel macht diese Rückgewinnung möglich und gehört nur auf die annehmende Seite. Alles Folgende ergibt sich daraus, wo diese drei Objekte liegen.

Lesen Sie die Tabelle nach Verwahrung statt nach Namen, und die Folgen fallen heraus. Den Wickelschlüssel zu verlieren ist das teure Ereignis, weil nichts im Profil ihn rekonstruieren kann und die ehrliche Wiederherstellung das Neuausstellen der Gruppe ist. Ein geleaktes Profil ist billiger, aber weit häufiger, weil Profile von Leuten in Tickets eingefügt werden, die glauben, die eingewickelte Kopie mache die Datei sicher zum Teilen. Die beiden Fehler brauchen unterschiedliche Antworten, und deshalb werden die Objekte getrennt gehalten.

Warum die eingewickelte Kopie nicht die ganze Geschichte ist

Ein Profil trägt das nutzbare Clientmaterial zusammen mit seinem eingewickelten Gegenstück, sodass der Schutz der Kopie für den Server nichts über den Schutz der Datei aussagt. Der Blob ist sicher zu übertragen und unsicher zu veröffentlichen. Die Metadaten darin sind für jeden sichtbar, der den Blob erhält, auch für jeden, der später das Ticket liest, in das er eingefügt wurde.

Behandeln Sie ein Profil als Nachweis, nicht als Konfigurationsbeispiel. Eine geleakte Datei gibt ihrem Besitzer eine funktionierende Client-Identität, bis der Server diese Identität nicht mehr annimmt, und die Einwicklung tut nichts gegen dieses Zeitfenster. Stellen Sie ein Profil pro Client aus, damit der Rückzug eine Entscheidung über eine Datei bleibt, und sichern Sie den Wickelschlüssel getrennt von der Serverkonfiguration, die er ermöglicht. Keine der beiden Gewohnheiten repariert ein kompromittiertes Profil, aber beide entscheiden, wie schnell das nächste eingedämmt wird.

Wo der Prüf-Hook im Handshake sitzt

Der Prüf-Hook läuft, bevor der TLS-Stack exponiert wird, und seine Aufgabe ist, die im eingewickelten Blob mitgeführten Metadaten zu prüfen. Er erhält diese Metadaten plus eine kleine, dokumentierte Umgebung und hat weniger zur Verfügung als ein Authentifizierungs-Hook. Anzunehmen, er sehe Benutzernamen, Sitzungszustand oder Plugin-Variablen, ist der übliche Weg, diesen Hook schlecht zu schreiben. Lesen Sie den eigenen Handbuchabschnitt des Hooks, statt Erwartungen von einem anderen Hook zu leihen.

Sein Exit-Status ist die Entscheidung: ein von null verschiedenes Ergebnis weist den Client ab, ein Nullergebnis lässt den Handshake weiterlaufen. Die Richtlinie muss also sagen, was passiert, wenn Metadaten fehlen, nicht lesbar oder unerwartet sind. Schreiben Sie zuerst den Ablehnungspfad und entscheiden Sie dann, welche Werte zulässig sind.

tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.sh

Diese beiden Zeilen sind die Richtlinienoberfläche auf dem Server: die eine benennt den Wickelschlüssel, die andere das Programm, das jeden Client beurteilt. Alles Interessante lebt im Skript, das Versionskontrolle und dieselbe Prüfung wie jede andere Zugriffsregel verdient.

Konto, Zertifikat und Steuerschlüssel werden getrennt zurückgezogen

Frühe Annahme des Steuerkanals ist keine Authentifizierung, weil sie vor der TLS-Identitätsprüfung und vor jeder Kontogewährung geschieht. Ein Konto zu deaktivieren, ein Zertifikat zu widerrufen und einen Client-Steuerschlüssel abzulehnen sind drei Vorgänge mit drei Mechanismen. Ein Deployment, das nur einen davon ausführt, hat eine Lücke statt einer Richtlinie. Gleichen Sie die drei bewusst ab und halten Sie fest, welcher Schritt welche Befugnis ausübt.

Der Zeitpunkt ist die zweite Unterscheidung. Eine geänderte Annahmeliste gilt für neue Handshakes, während bereits aufgebaute Sitzungen weiterlaufen, bis etwas sie beendet. Einträge der neuen Liste als Beweis zu zählen, dass alte Sitzungen beendet sind, ist der Weg, auf dem ein entfernter Client stundenlang verbunden bleibt.

Nicht abgeglichene Befugnisse hinterlassen zwei Lücken, die in der Praxis leicht zu finden sind. Ein Konto kann deaktiviert sein, während sein Steuerschlüssel noch einen Handshake öffnet, und ein Zertifikat kann widerrufen sein, während die Metadatenrichtlinie denselben Client noch zulässt. Beides ist derselbe Fehler an verschiedenen Stellen, weil ein Betreiber eine Liste als die ganze Befugnis behandelt hat. Legen Sie die drei Listen beim Entfernen nebeneinander, und der Fehler wird sichtbar.

Ein Profil ausstellen und zurückziehen

Ausstellen ist die leichte Hälfte: Erzeugen Sie den Client-Schlüssel auf der annehmenden Seite, geben Sie das Profil genau einem Eigentümer, halten Sie das Wickelmaterial beschränkt und führen Sie dasselbe Prüfprogramm auf jedem annehmenden Server aus. Billiger Zutritt ist eine Eigenschaft der ganzen Gruppe, nicht des neuesten Hosts. Ein zweiter Server mit einem älteren oder lockereren Skript wird stillschweigend zum schwächsten Weg im Deployment.

Der Rückzug braucht die drei Schritte in einer bewussten Reihenfolge. Weisen Sie den Client im Prüf-Hook ab, damit neue Handshakes scheitern, widerrufen Sie sein Zertifikat, falls eine PKI verwendet wird, und deaktivieren Sie das Konto, damit spätere Autorisierung nichts zu autorisieren hat. Beenden Sie dann die Sitzungen, die die alte Annahme erlaubte, denn sie werden nichts von den dreien bemerken. Üben Sie die Reihenfolge an einem Client, den Sie sich leisten können zu brechen.

Metadaten in einem Profil sind eine Eingabe für diese Richtlinie, kein Beweis, dass Zugriffskontrolle bereits existiert. Das OpenVPN-2.6-Designdokument beschreibt die Objekte und die Grenze, die sie ziehen, während die Durchsetzung beim Betreiber bleibt.