0x of 0s? Ontleed die PSK-formaat in ipsec.secrets

Een kliënt verifieer met die gedeelde sleutel en ’n ander verwerp dit, en die karakters wat jy geplak het lyk op beide kante dieselfde. Hulle is waarskynlik dieselfde karakters; die verskil is watter dekoderingsreël die lêer daarop toepas. ’n Aangehaalde string word letterlik geneem, ’n teken wat met 0x begin, word as heksadesimaal gelees, en ’n teken wat met 0s begin, word as Base64 gelees. Net een van daardie drie spellings beteken wat jy bedoel het, so die regstelling is gewoonlik ’n omskakeling eerder as ’n beter wagwoord.

Die simptoom dui op enkodering, nie op syfers nie

Wanneer die twee kante verskillende grepe hou, slaag die onderhandeling steeds en misluk die bewys daarna. Die log meld dan ’n integriteits- of HMAC-fout eerder as ’n algoritmewanpassing, want ’n voorstel is gekies en die verifikasiestap het nie ooreengestem nie. Daardie reël noem nooit die vorm van die geheim nie.

Die stadium is die leidraad. ’n Fout wat ná ’n gekose voorstel opduik, beteken beide kante het oor alles behalwe sleutelmateriaal ooreengekom, terwyl “geen voorstel gekies nie” by beleid of syferreekse hoort. ’n Integriteitskontrole wat misluk terwyl die wagwoord reg lyk, is die sigbare gesig van ’n enkoderingswanpassing.

Een geheim, drie maniere waarop die lêer dit kan lees

Vir die viergrepewaarde key1 is heksadesimaal en Base64 twee her-enkoderings van dieselfde grepe, en net die voorste karakters sê vir die ontleder watter een hy in die hand het. swanctl-geloofsbriewe volg dieselfde konvensie, so ’n waarde wat tussen die twee koppelvlakke geskuif word, behou sy betekenis net wanneer sy voorvoegsel saam met hom reis.

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

Twee besonderhede in daardie blok kos die meeste tyd. Heksadesimale syfers aanvaar enige van die twee gevalle, so 0x6b657931 en 0x6B657931 is dieselfde waarde, maar ’n onewe aantal karakters word stilweg verkeerd gelees eerder as verwerp, wat elke greep ná die snypunt verskuif. Base64-opvulling hoort by die waarde, so ’n string wat sonder sy agterste = tekens geplak word, dekodeer in ander grepe in plaas daarvan om hardop te misluk.

’n Profiel wat die waarde een keer gedekodeer het, het dit reeds omgeskakel, so om weer te dekodeer lewer ander grepe en ’n verifikasiefout wat soos ’n verkeerde wagwoord lees. Aanhaling is die veilige rigting vir enigiets dubbelsinnig, want die inhoud is letterlik selfs wanneer dit met ’n enkoderingsmerker begin.

Waar die Base64-teks vandaan kom

Profieluitvoer en verskafferportale oorhandig dikwels die sleutel reeds geënkodeer, gewoonlik in ’n dataveld wat nooit bedoel was om met die hand getik te word nie. Wikkel daardie waarde óf oop en stoor die gedekodeerde teks in aanhalingstekens, óf laat dit geënkodeer met die merker voor. Om die helfte van elkeen te doen, is wat breek. Enige van die twee weë werk net as die hele waarde die kopie oorleef.

Albei rigtings is een opdrag elk, en dit is die moeite werd om hulle in die kaartjie te hou as die presiese bewerking wat die gestoorde waarde opgelewer het. Voer hulle in hierdie volgorde uit:

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

Om geënkodeerde teks te plak asof dit gewoon is, is die duur fout. Die lêer hash die karakters presies soos geskryf, die afgeleide sleutel kom ongeveer ’n derde langer uit as die een wat die eweknie bereken het, en elke poging misluk op dieselfde manier sonder ’n waarskuwing, want die ontleder het die reël gevolg wat aan hom gegee is.

Bevestig watter grepe elke eweknie werklik gebruik

Lees eers die daemon se siening van die verbinding en tweedens die verifikasie-uitslag, eerder as om ’n oorsaak uit die foutstring te raai. Om die gestoorde lengte te vergelyk is ’n vinnige redelikheidskontrole, want geënkodeerde teks is langer as die grepe wat dit verteenwoordig. Bevestig dan watter identiteitsry ooreengestem het, want ’n korrekte geheim wat onder die verkeerde eweknie geliasseer is, misluk identies aan ’n verkeerde een. Ryorde besluit dit: die eerste ooreenkoms wen, so ’n breë %any-reël naby die bokant vervang stilweg die spesifieke ry wat jy pas geredigeer het.

Herlaai eerder as om te herbegin sodra die lêer reg is. ipsec rereadsecrets verfris die IKE-daemon se kopie, en ’n swanctl-opstelling laai geloofsbriewe deur sy eie opdrag. ’n Herbegin laat elke gevestigde assosiasie val en vernietig die vergelyking wat jy probeer maak het.

Nie een van hierdie kontroles vereis dat die geheim blootgestel word nie. ’n Lengte, ’n identiteitskeuse en ’n ryposisie verduidelik die meeste foute van hierdie soort voordat iemand ’n heksuitvoer nodig het.

Verander die lêer sonder om die resultaat weg te steek

Beperk die lêer tot die daemon se rekening, en hou lewende geheime uit kaartjies, klets en skermkiekies, want ’n geplakte sleutel is ’n lek eerder as ’n diagnose. Dit oorleef ook die voorval wat dit opgelewer het.

Toets vanaf ’n kliënt wie se konfigurasie jy beheer, bevestig dat verifikasie slaag, en bevestig dan dat die tonnel verkeer dra. ’n Herlaai wat die handdruk regmaak terwyl roetering stukkend bly, is ’n ander probleem, en dit word sigbaar sodra die geheim ophou beweeg.