Vorab geteilter IPsec-Schlüssel: die Bytes hinter der Zeichenfolge, die Sie eingegeben haben

Zwei Administratoren vergleichen das Geheimnis auf dem Bildschirm, stimmen überein, dass es passt, und der Tunnel scheitert trotzdem an der Authentifizierung. Die Zeichenfolge, die sie verglichen haben, ist nicht der Wert, den einer der beiden Enden in die Schlüsselableitung einspeist. Zwischen den Zeichen, die Sie sehen, und den Bytes, die das Protokoll hasht, liegen ein Feldtyp, eine Textkodierung, ein Editor und eine Zwischenablage, und jedes der vier kann die Eingabe ändern, ohne das Aussehen zu verändern. Vergleichen Sie die Bytes, und die Abweichung zeigt sich meist in Sekunden.

Was das Gateway mit der Zeichenfolge macht

Ein vorab geteilter Schlüssel wird nicht über die Leitung gesendet und verglichen. Jede Seite speist ihre lokale Kopie in die Schlüsselableitung für den IKE-Austausch ein, und die resultierenden Authentifizierungsnutzlasten werden entweder verifiziert oder nicht. Dieses Design bedeutet, dass die beiden Kopien byte-identisch und nicht nur visuell ähnlich sein müssen, und es bedeutet auch, dass der Fehler in der Authentifizierungsphase gemeldet wird und nicht als Meldung über ein falsches Passwort.

Die nützliche Frage lautet also nie „sehen diese gleich aus“, sondern „welche genaue Bytefolge hasht jede Implementierung“.

Woher zusätzliche Bytes kommen

Ein abschließender Zeilenumbruch ist der klassische Übeltäter, und er versteckt sich offen, weil die meisten Editoren beim Speichern einer Datei unsichtbar einen hinzufügen. Ein führendes oder abschließendes Leerzeichen, das aus einem Chatfenster eingefügt wurde, tut dasselbe, und ein typografisches Anführungszeichen, das eine Textverarbeitung durch ein gerades ersetzt hat, ebenfalls. Nichts davon ändert den visuellen Vergleich, den ein Mensch durchführt.

Vergleichen Sie mit einem Werkzeug, das Bytes statt Glyphen anzeigt. printf '%s' "$PSK" | xxd | tail -2 gibt das Ende des Werts in Hex aus, wo ein verirrtes 0a oder 20 offensichtlich ist. Tun Sie das an beiden Enden und vergleichen Sie die beiden Dumps nebeneinander. Tun Sie das mit generiertem Testmaterial, nicht mit einem Produktionsgeheimnis, das Sie anschließend in der Shell-Historie hinterlassen.

Kodiert ist nicht verschlüsselt

Konfigurationsexporte tragen das Geheimnis häufig in einer Basiskodierung, manchmal mit Zeilenumbrüchen alle sechzig oder sechsundsiebzig Zeichen und manchmal mit Auffüllung. Wenn ein Ende die dekodierten Bytes erwartet und Sie den kodierten Text einfügen, haben Sie kein anderes Passwort gesendet, sondern ein viel längeres aus druckbaren Zeichen. Base64 bietet keinerlei Vertraulichkeit, weshalb ein kodiertes Geheimnis niemals in einem Forum für eine zweite Meinung eingefügt werden darf.

Apples IPSec-Wörterbuch ist ein gutes Beispiel dafür, dass der Typ zählt: Es dokumentiert SharedSecret als Daten für die Authentifizierungsmethode mit gemeinsamem Geheimnis in den L2TP- und Cisco-IPsec-Nutzlasten. Das ist eine bestimmte Eigenschaft in einer bestimmten Nutzlast, kein allgemeines Textfeld, das Sie für ein anderes Protokoll wiederverwenden können, das zufällig ein Geheimnis verlangt.

Ein behauptetes Limit gehört zu einer Kombination

Alte Berichte über eine Obergrenze von zweiunddreißig Zeichen bei einem Apple-Client sind echte Berichte über eine Client-Version, ein Protokoll und eine Profilform. Sie sind kein universelles Limit für jede Apple-Plattform, jeden Anbieter und jedes Protokoll. Prüfen Sie Version, Nutzlasttyp und Gateway-Anforderung zusammen und testen Sie dann mit einer genehmigten Konfiguration, statt aus einem Thread zu schließen. Schreiben Sie die getestete Kombination in den Änderungsdatensatz, sonst zitiert die nächste Person denselben Thread mit mehr Zuversicht, als er verdient.

Wenn ein Limit tatsächlich gilt, ist die Antwort ein unterstütztes Anmeldedaten-Design, das dazu passt, keine verkürzte Version eines starken Geheimnisses. Das Kürzen eines Produktionsschlüssels, um ein vermutetes Limit zu erfüllen, verringert seine Stärke dauerhaft und erzeugt ein System, dessen Dokumentation nicht mehr zu seiner Sicherheit passt.

Korrigieren Sie die Darstellung, nicht die Stärke

Wenn die Authentifizierung fehlschlägt, nachdem die Darstellung bestätigt wurde, lesen Sie die effektive Richtlinie in der Authentifizierungsphase: welche Methode ausgehandelt wird, welche Peer-Identität erwartet wird und ob das Gateway zu der Verbindung passt, die Sie vermuten. Allmählich schwächere Vermutungen sind keine Diagnose, sondern ein langsames Herabstufen mit einem angehängten Support-Ticket.

Wenn die erforderlichen Anmeldedaten den Standard der Organisation nicht erfüllen können, ändern Sie das Design auf eines, das es kann. Ein gemeinsames Geheimnis mit ausreichender Entropie, einmal generiert, in einem verwalteten Feld gespeichert und nie veröffentlicht, ist eine vollkommen gute Antwort; eine kürzere Version davon nicht.