Warum openssl rand den Schlüssel für tls-crypt nicht erzeugen kann

OpenSSL ist bereits installiert, der Host verfügt über Entropie, und damit einen Schlüssel zu erzeugen wirkt wie die naheliegende Abkürzung. Die Ausgabe wird zufällig und geheim und völlig unbrauchbar sein, und der Fehler erscheint als Fehler im Kontrollkanal statt als etwas, das ein Schlüsselformat erwähnt. Diese Fehlleitung ist der teure Teil, weil sie Leute dazu bringt, ihre Chiffren zu untersuchen. Was das VPN liest, ist eine bestimmte Dateistruktur, kein beliebiger Byteblock, und eine Variante der Funktion lässt sich außerhalb des Servers überhaupt nicht erzeugen.

Was die Datei auf der Platte tatsächlich sein muss

Eine statische Schlüsseldatei von OpenVPN ist Text. Sie beginnt mit einer Kommentarzeile, die angibt, was sie ist, enthält Hex-Daten in Zeilen fester Breite und umfasst insgesamt 256 Bytes Schlüsselmaterial. OpenVPN liest sie als gemeinsames Geheimnis des Kontrollkanals, nicht als Zertifikat, nicht als Passphrase und nicht als etwas, das eine TLS-Bibliothek erkennen würde.

Derselbe Objekttyp dient beiden Funktionen des Kontrollkanals. Bei tls-auth braucht jeder Peer zusätzlich eine Richtung, damit die Pakete einer Seite nicht zu ihr zurückgeworfen werden können. Bei tls-crypt verschlüsselt und authentifiziert ein einziges gemeinsames Geheimnis den Kontrollkanal in beide Richtungen, was den Handshake verbirgt und zugleich schützt.

Nichts davon ist geheimes Wissen, und das Format ist nicht der Punkt. Der Punkt ist, dass die Datei genau dem entsprechen muss, was der Leser erwartet: Kopfzeile, Zeilenbreite, abschließender Zeilenumbruch und Gesamtlänge. Eine Datei, die um eine Zeile danebenliegt, lädt als Müll oder scheitert überhaupt. Zwei Peers Byte für Byte zu vergleichen ist daher ein legitimer erster Test, und er ist schneller, als eine der beiden Konfigurationsdateien zu lesen.

Der unterstützte Weg, einen zu erzeugen

Erzeugen Sie den einfachen statischen Schlüssel mit dem Werkzeug, das ihn verwenden wird, und referenzieren Sie ihn dann an beiden Enden:

openvpn --genkey secret /etc/openvpn/tc-shared.key
tls-crypt /etc/openvpn/tc-shared.key

Die Schreibweise der Option änderte sich im Laufe der Zeit: Ältere Installationen aus der 2.4-Ära verwendeten eine Form mit einem separaten Flag vor dem Dateinamen, während aktuelle Builds die kürzere akzeptieren. So oder so ist die resultierende Datei dieselbe Art von Objekt, daher ist die Prüfung, ob beide Peers identische Bytes halten.

Die zweite Generation fügt eine Struktur hinzu, die kein externer Generator erfinden kann. Ein Serverschlüssel wird einmal erstellt, und jeder Client erhält einen daraus abgeleiteten eingewickelten Schlüssel:

openvpn --genkey tls-crypt-v2-server /etc/openvpn/tc-v2-server.key
openvpn --genkey tls-crypt-v2-client /etc/openvpn/laptop1.key --tls-crypt-v2 /etc/openvpn/tc-v2-server.key

Was der Client erhält, ist nicht der eigene Schlüssel des Servers, dupliziert. Es ist ein eingewickeltes Objekt mit Metadaten, die nur der Server auspacken kann, und diese Einwicklung ist der Grund, warum eine Datei pro Gerät widerrufen werden kann, ohne ein anderes Gerät zu berühren. Bewahren Sie den Serverschlüssel auf dem Server auf und behandeln Sie ihn als Wurzel dieses Vertrauens pro Gerät.

Wo handgemachte Bytes scheitern

256 zufällige Bytes als Hex unter einer korrekten Kopfzeile auszugeben würde theoretisch eine statische Schlüsseldatei ergeben, die lädt. Es bleibt eine schlechte Idee. Jedes Formatierungsdetail wird zu einer Chance, Material zu erzeugen, das beim Laden scheitert oder, schlimmer, zwei Peers mit unterschiedlichen Werten zurücklässt, die sich erst als Authentifizierungsfehler zeigen.

Mit der v2-Variante ist nichts Vergleichbares möglich. Ein eingewickelter Client-Schlüssel existiert nur als Ausgabe des Server-Schlüsselprozesses, und der Server behält das Material, das zum Auspacken nötig ist. Ein zufälliger Blob wird abgelehnt oder schlägt einfach beim Entschlüsseln fehl, und keine der beiden Meldungen erwähnt Zufälligkeit.

Die Versionskompatibilität steht über allem. Die erste Generation braucht eine Version, die sie an beiden Enden unterstützt, und die zweite braucht wieder eine neuere Version. Ein Client, der vor der Existenz der Funktion gebaut wurde, kann keinen Handshake mit einem Server abschließen, der nur eingewickeltes Material akzeptiert, und der gemeldete Fehler zeigt auf den Kontrollkanal statt auf die Version.

Rotieren, ohne alle auszusperren

Ein einziges gemeinsames Geheimnis zu rotieren ist eine Koordinationsübung, keine technische. Jeder Client braucht die Ersatzdatei zur Hand, bevor der Server die vorherige zurückzieht, und jede Maschine, die noch den alten Wert hält, scheitert in dem Moment. Beginnen Sie diese Rotation nicht mitten am Arbeitstag.

Mit der v2-Anordnung erfolgt die Rotation pro Gerät: Stellen Sie einen neuen eingewickelten Schlüssel für eine Maschine aus und ziehen Sie den alten nur für diese Maschine zurück. Das ist das Hauptargument für den Umstieg, sobald jeder Client auf einer Version ist, die ihn unterstützt.

Dateiberechtigungen gehören in dasselbe Gespräch. Der Schlüssel sollte nur für das Konto lesbar sein, das den Dienst ausführt, und er sollte nicht im selben Repository liegen wie die Profile, die er schützt. Die OpenVPN-2.6-Referenz dokumentiert die Erzeugungsformen und die Abschnitte zum Schlüsselmaterial, was eine bessere Quelle ist als ein kopierter Befehl aus einem Forumsbeitrag.