0x oder 0s? Das PSK-Format in ipsec.secrets entschlüsseln

Dasselbe gemeinsame Geheimnis lässt sich als zitiertes Literal, als Hexadezimalwert nach 0x oder als Base64 nach 0s schreiben. Ein falsches Präfix lässt die Authentifizierung scheitern, nicht die Aushandlung.

Ein Client authentifiziert sich mit dem gemeinsamen Schlüssel, ein anderer weist ihn zurück, und die eingefügten Zeichen sehen auf beiden Seiten gleich aus. Wahrscheinlich sind es dieselben Zeichen; der Unterschied liegt darin, welche Dekodierregel die Datei darauf anwendet. Eine Zeichenkette in Anführungszeichen wird wörtlich genommen, ein Token, das mit 0x beginnt, wird als Hexadezimalwert gelesen, und ein Token, das mit 0s beginnt, wird als Base64 gelesen. Nur eine dieser drei Schreibweisen bedeutet, was Sie beabsichtigt haben, deshalb ist die Lösung meist eine Umwandlung und kein besseres Passwort.

Das Symptom deutet auf Kodierung, nicht auf Chiffren

Wenn beide Seiten unterschiedliche Bytes halten, gelingt die Aushandlung trotzdem, und der Nachweis scheitert danach. Das Protokoll meldet dann einen Integritäts- oder HMAC-Fehler statt einer Algorithmusabweichung, weil ein Vorschlag gewählt wurde und der Authentifizierungsschritt nicht passte. Diese Zeile erwähnt nie die Form des Geheimnisses.

Die Phase ist der Hinweis. Ein Fehler nach einem gewählten Vorschlag bedeutet, dass sich beide Seiten über alles außer dem Schlüsselmaterial einig waren, während „kein Vorschlag gewählt“ zu Richtlinie oder Chiffresuiten gehört. Eine Integritätsprüfung, die scheitert, obwohl das Passwort richtig aussieht, ist die sichtbare Seite einer Kodierungsabweichung.

Ein Geheimnis, drei Arten, wie die Datei es lesen kann

Für den Wert aus vier Bytes key1 sind Hexadezimal und Base64 zwei Neukodierungen derselben Bytes, und nur die führenden Zeichen sagen dem Parser, welche davon er hält. swanctl-Anmeldedaten folgen derselben Konvention, deshalb behält ein zwischen den beiden Schnittstellen verschobener Wert seine Bedeutung nur, wenn sein Präfix mitwandert.

10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==

Zwei Details in diesem Block kosten die meiste Zeit. Hexadezimale Ziffern akzeptieren beide Schreibweisen, also sind 0x6b657931 und 0x6B657931 derselbe Wert, aber eine ungerade Zeichenzahl wird still falsch gelesen statt abgelehnt, was jedes Byte nach dem Schnitt verschiebt. Base64-Auffüllung gehört zum Wert, deshalb wird eine Zeichenkette, die ohne ihre abschließenden = Zeichen eingefügt wird, in andere Bytes dekodiert, statt laut zu scheitern.

Ein Profil, das den Wert einmal dekodiert hat, hat ihn bereits umgewandelt, deshalb erzeugt erneutes Dekodieren andere Bytes und einen Authentifizierungsfehler, der wie ein falsches Passwort aussieht. Anführungszeichen sind die sichere Richtung für alles Mehrdeutige, weil der Inhalt wörtlich ist, auch wenn er mit einer Kodierungsmarke beginnt.

Woher der Base64-Text kommt

Profil-Exporte und Anbieterportale übergeben den Schlüssel oft schon kodiert, meist in einem Datenfeld, das nie zum Abtippen gedacht war. Entweder wickeln Sie diesen Wert aus und speichern den dekodierten Text in Anführungszeichen, oder Sie lassen ihn mit der Marke davor kodiert. Von beidem die Hälfte zu tun, ist das, was es kaputt macht. Beide Wege funktionieren nur, wenn der ganze Wert das Kopieren übersteht.

Beide Richtungen sind je ein Befehl, und sie gehören als die genaue Operation, die den gespeicherten Wert erzeugt hat, ins Ticket. Führen Sie sie in dieser Reihenfolge aus:

printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64

Kodierten Text einzufügen, als wäre er Klartext, ist der teure Fehler. Die Datei hasht die Zeichen genau so, wie sie geschrieben stehen, der abgeleitete Schlüssel wird rund ein Drittel länger als der, den die Gegenseite berechnet hat, und jeder Versuch scheitert auf dieselbe Weise ohne Warnung, weil der Parser der Regel folgte, die ihm gegeben wurde.

Bestätigen Sie, welche Bytes jede Gegenseite tatsächlich verwendet

Lesen Sie zuerst die Sicht des Daemons auf die Verbindung und dann das Authentifizierungsergebnis, statt eine Ursache aus der Fehlerzeichenkette zu raten. Die gespeicherte Länge zu vergleichen ist eine schnelle Plausibilitätsprüfung, denn kodierter Text ist länger als die Bytes, die er darstellt. Bestätigen Sie dann, welche Identitätszeile passte, denn ein korrektes Geheimnis unter der falschen Gegenseite scheitert genauso wie ein falsches. Die Zeilenreihenfolge entscheidet das: Der erste Treffer gewinnt, also ersetzt eine breite %any-Zeile nahe oben still die spezifische Zeile, die Sie gerade bearbeitet haben.

Laden Sie neu, statt neu zu starten, sobald die Datei stimmt. ipsec rereadsecrets frischt die Kopie des IKE-Daemons auf, und ein swanctl-Setup lädt Anmeldedaten über seinen eigenen Befehl. Ein Neustart verwirft jede bestehende Assoziation und zerstört den Vergleich, den Sie anstellen wollten.

Keine dieser Prüfungen erfordert es, das Geheimnis offenzulegen. Eine Länge, ein Identitätsselektor und eine Zeilenposition erklären die meisten Fehler dieser Art, bevor jemand einen Hex-Dump braucht.

Ändern Sie die Datei, ohne das Ergebnis zu verbergen

Beschränken Sie die Datei auf das Konto des Daemons und halten Sie lebende Geheimnisse aus Tickets, Chats und Screenshots heraus, denn ein eingefügter Schlüssel ist ein Leck und keine Diagnose. Er überlebt auch den Vorfall, der ihn hervorgebracht hat.

Testen Sie von einem Client aus, dessen Konfiguration Sie kontrollieren, bestätigen Sie, dass die Authentifizierung gelingt, und bestätigen Sie dann, dass der Tunnel Verkehr führt. Ein Neuladen, das den Handshake repariert, während das Routing kaputt bleibt, ist ein anderes Problem, und es wird sichtbar, sobald das Geheimnis aufhört, sich zu bewegen.

Ähnliche Artikel