0x eller 0s? Sådan læses PSK-formatet i ipsec.secrets

Én klient godkender med den fælles nøgle, og en anden afviser den, selv om tegnene, du indsatte, ser ens ud på begge sider. De er sandsynligvis de samme tegn; forskellen er, hvilken afkodningsregel filen anvender på dem. En streng i anførselstegn tages bogstaveligt, et token, der begynder med 0x læses som hexadecimal, og et token, der begynder med 0s læses som Base64. Kun én af de tre stavemåder betyder det, du havde tænkt dig, så rettelsen er som regel en konvertering og ikke en bedre adgangskode.

Symptomet peger på kodning, ikke på cifre

Når de to ender har forskellige bytes, lykkes forhandlingen stadig, og beviset fejler bagefter. Loggen rapporterer så en integritets- eller HMAC-fejl i stedet for en algoritmeforskel, fordi et forslag blev valgt, og godkendelsestrinet ikke passede. Den linje nævner aldrig hemmelighedens form.

Trinnet er sporingspunktet. En fejl, der kommer efter et valgt forslag, betyder, at begge sider blev enige om alt undtagen nøglemateriale, mens »intet forslag valgt« hører til politik eller cifre-sæt. En integritetskontrol, der fejler, mens adgangskoden ser rigtig ud, er den synlige side af en kodningsforskel.

Én hemmelighed, tre måder filen kan læse den på

For værdien på fire bytes key1 er hexadecimal og Base64 to omkodninger af de samme bytes, og kun de førende tegn fortæller parseren, hvilken af dem den holder. swanctl-legitimationsoplysninger følger samme konvention, så en værdi, der flyttes mellem de to grænseflader, bevarer kun sin betydning, når dens præfiks flytter med.

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

To detaljer i den blok koster mest tid. Hexadecimale cifre accepterer begge skrivemåder, så 0x6b657931 og 0x6B657931 er den samme værdi, men et ulige antal tegn læses stille forkert i stedet for at blive afvist, hvilket flytter hver byte efter snittet. Base64-udfyldning hører til værdien, så en streng, der indsættes uden sine afsluttende = tegn, afkodes til andre bytes i stedet for at fejle højlydt.

En profil, der én gang har afkodet værdien, har allerede konverteret den, så afkodning igen giver andre bytes og en godkendelsesfejl, der læses som en forkert adgangskode. Anførselstegn er den sikre retning for alt tvetydigt, fordi indholdet er bogstaveligt, selv når det begynder med en kodningsmarkør.

Hvor Base64-teksten kommer fra

Profiludtræk og leverandørportaler giver ofte nøglen allerede kodet, normalt i et datafelt, der aldrig var beregnet til at blive tastet i hånden. Enten udpak den værdi og gem den afkodede tekst i anførselstegn, eller lad den være kodet med markøren foran. At gøre halvdelen af hver er det, der ødelægger det. Begge veje virker kun, hvis hele værdien overlever kopieringen.

Begge retninger er én kommando hver, og de er værd at gemme i ticketen som den præcise handling, der frembragte den gemte værdi. Kør dem i denne rækkefølge:

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

At indsætte kodet tekst, som om den var almindelig, er den dyre fejl. Filen hasher tegnene præcis som skrevet, den afledte nøgle bliver cirka en tredjedel længere end den, modparten beregnede, og hvert forsøg fejler på samme måde uden advarsel, fordi parseren fulgte den regel, den fik.

Bekræft, hvilke bytes hver modpart faktisk bruger

Læs først daemonens syn på forbindelsen og derefter godkendelsesresultatet, i stedet for at gætte en årsag ud fra fejlstrengen. At sammenligne den gemte længde er et hurtigt rimelighedstjek, fordi kodet tekst er længere end de bytes, den repræsenterer. Bekræft derefter, hvilken identitetsrække der matchede, fordi en korrekt hemmelighed, der ligger under den forkerte modpart, fejler præcis som en forkert. Rækkefølgen afgør det: det første match vinder, så en bred %any linje nær toppen erstatter stille den specifikke række, du netop redigerede.

Genindlæs i stedet for at genstarte, når filen er rigtig. ipsec rereadsecrets opdaterer IKE-daemonens kopi, og et swanctl-opsætning indlæser legitimationsoplysninger via sin egen kommando. En genstart dropper hver etableret association og ødelægger den sammenligning, du forsøgte at lave.

Ingen af disse kontroller kræver at afsløre hemmeligheden. En længde, en identitetsvælger og en rækkeposition forklarer de fleste fejl af denne slags, før nogen har brug for et hex-dump.

Ret filen uden at skjule resultatet

Begræns filen til daemonens konto, og hold levende hemmeligheder ude af tickets, chat og skærmbilleder, fordi en indsat nøgle er en lækage og ikke en diagnosticering. Den overlever også den hændelse, der frembragte den.

Test fra en klient, hvis konfiguration du styrer, bekræft at godkendelsen lykkes, og bekræft derefter, at tunnelen bærer trafik. En genindlæsning, der retter håndtrykket, mens routing forbliver brudt, er et andet problem, og det bliver synligt, så snart hemmeligheden holder op med at flytte sig.