0x of 0s? Het PSK-formaat in ipsec.secrets lezen

De ene client authenticeert met de gedeelde sleutel en de andere wijst hem af, terwijl de tekens die u plakt er aan beide kanten hetzelfde uitzien. Het zijn waarschijnlijk dezelfde tekens; het verschil zit in welke decoderingsregel het bestand erop toepast. Een tekenreeks tussen aanhalingstekens wordt letterlijk genomen, een token dat begint met 0x wordt als hexadecimaal gelezen, en een token dat begint met 0s wordt als Base64 gelezen. Slechts één van die drie schrijfwijzen betekent wat u bedoelde, dus de oplossing is meestal een conversie en niet een beter wachtwoord.

Het symptoom wijst op codering, niet op cijfers

Wanneer beide uiteinden verschillende bytes hebben, slaagt de onderhandeling toch en faalt het bewijs daarna. Het log meldt dan een integriteits- of HMAC-fout in plaats van een algoritmeverschil, omdat er een voorstel is gekozen en de authenticatiestap niet klopte. Die regel noemt nooit de vorm van het geheim.

De fase is de aanwijzing. Een fout die na een gekozen voorstel komt, betekent dat beide kanten het over alles eens waren behalve over sleutelmateriaal, terwijl «geen voorstel gekozen» bij beleid of cijfersuites hoort. Een integriteitscontrole die faalt terwijl het wachtwoord er goed uitziet, is het zichtbare gezicht van een coderingsverschil.

Eén geheim, drie manieren waarop het bestand het kan lezen

Voor de waarde van vier bytes key1 zijn hexadecimaal en Base64 twee hercoderingen van dezelfde bytes, en alleen de voorste tekens vertellen de parser welke van de twee hij vasthoudt. swanctl-inloggegevens volgen dezelfde conventie, dus een waarde die tussen de twee interfaces wordt verplaatst, behoudt zijn betekenis alleen als het voorvoegsel meereist.

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

Twee details in dat blok kosten de meeste tijd. Hexadecimale cijfers accepteren beide schrijfwijzen, dus 0x6b657931 en 0x6B657931 zijn dezelfde waarde, maar een oneven aantal tekens wordt stil verkeerd gelezen in plaats van afgewezen, waardoor elke byte na de knip verschuift. Base64-opvulling hoort bij de waarde, dus een tekenreeks die zonder de afsluitende = tekens wordt geplakt, decodeert naar andere bytes in plaats van luid te falen.

Een profiel dat de waarde één keer heeft gedecodeerd, heeft hem al omgezet, dus opnieuw decoderen levert andere bytes op en een authenticatiefout die als een verkeerd wachtwoord leest. Aanhalingstekens zijn de veilige richting voor alles wat dubbelzinnig is, omdat de inhoud letterlijk is, ook wanneer die met een coderingsmarkering begint.

Waar de Base64-tekst vandaan komt

Profilexporten en leveranciersportalen geven de sleutel vaak al gecodeerd door, meestal in een gegevensveld dat nooit bedoeld was om met de hand te typen. Ofwel pakt u die waarde uit en bewaart u de gedecodeerde tekst tussen aanhalingstekens, ofwel laat u hem gecodeerd met de markering ervoor. Van beide de helft doen is wat het breekt. Beide wegen werken alleen als de hele waarde het kopiëren overleeft.

Beide richtingen zijn elk één opdracht, en ze zijn het waard om in de ticket te bewaren als de exacte handeling die de opgeslagen waarde heeft gemaakt. Voer ze in deze volgorde uit:

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

Gecodeerde tekst plakken alsof het gewone tekst is, is de dure fout. Het bestand hasht de tekens precies zoals ze geschreven staan, de afgeleide sleutel wordt ongeveer een derde langer dan die de tegenpartij berekende, en elke poging faalt op dezelfde manier zonder waarschuwing, omdat de parser de regel volgde die hem was gegeven.

Controleer welke bytes elke tegenpartij werkelijk gebruikt

Lees eerst de kijk van de daemon op de verbinding en daarna het resultaat van de authenticatie, in plaats van een oorzaak uit de fouttekst te raden. De opgeslagen lengte vergelijken is een snelle gezondheidscontrole, omdat gecodeerde tekst langer is dan de bytes die hij vertegenwoordigt. Controleer daarna welke identiteitsregel overeenkwam, want een correct geheim onder de verkeerde tegenpartij faalt precies zoals een verkeerd geheim. De volgorde van de regels beslist dat: de eerste overeenkomst wint, dus een brede %any regel bovenaan vervangt stil de specifieke regel die u zojuist hebt bewerkt.

Herlaad in plaats van opnieuw te starten als het bestand eenmaal klopt. ipsec rereadsecrets ververst de kopie van de IKE-daemon, en een swanctl-opstelling laadt inloggegevens via zijn eigen opdracht. Een herstart gooit elke opgezette associatie weg en vernietigt de vergelijking die u probeerde te maken.

Geen van deze controles vereist dat het geheim wordt blootgelegd. Een lengte, een identiteitskeuze en een regelpositie verklaren de meeste van dit soort fouten voordat iemand een hexdump nodig heeft.

Wijzig het bestand zonder het resultaat te verbergen

Beperk het bestand tot het account van de daemon en houd levende geheimen buiten tickets, chat en schermafbeeldingen, want een geplakte sleutel is een lek en geen diagnose. Hij overleeft ook het incident dat hem heeft voortgebracht.

Test vanaf een client waarvan u de configuratie beheert, bevestig dat de authenticatie slaagt en bevestig daarna dat de tunnel verkeer draagt. Een herlaad die de handdruk repareert terwijl de routering kapot blijft, is een ander probleem, en het wordt zichtbaar zodra het geheim ophoudt te bewegen.