0x apo 0s? Si të lexohet formati PSK në ipsec.secrets

Një klient vërtetohet me çelësin e përbashkët dhe një tjetër e refuzon atë, ndonëse karakteret që ngjitët duken njësoj në të dyja anët. Me gjasë janë të njëjtat karaktere; ndryshimi është se cili rregull dekodimi zbaton skedari mbi to. Vargu midis thonjëzave merret fjalë për fjalë, një token që fillon me 0x lexohet si heksadecimal, dhe një token që fillon me 0s lexohet si Base64. Vetëm një nga këto tre shkrime do të thotë ajo që kishit ndërmend, prandaj rregullimi është zakonisht një konvertim dhe jo një fjalëkalim më i mirë.

Simptoma tregon kodimin, jo shifrat

Kur dy skajet mbajnë bajt të ndryshëm, negociatat përsëri ia dalin dhe prova dështon pas tyre. Regjistri atëherë raporton një dështim integriteti ose HMAC në vend të një mospërputhje algoritmi, sepse u zgjodh një propozim dhe hapi i vërtetimit nuk përputhej. Ai rresht nuk përmend kurrë formën e sekretit.

Faza është indicja. Një dështim që vjen pas një propozimi të zgjedhur do të thotë që të dyja palët u dakordësuan për gjithçka përveç materialit të çelësit, ndërsa «asnjë propozim i zgjedhur» i përket politikës ose grupeve të shifrave. Një kontroll integriteti që dështon ndërsa fjalëkalimi duket i saktë është fytyra e dukshme e një mospërputhje kodimi.

Një sekret, tre mënyra si skedari mund ta lexojë

Për vlerën prej katër bajtësh key1, heksadecimali dhe Base64 janë dy rikodifikime të të njëjtave bajt, dhe vetëm karakteret e para i thonë analizuesit se cilën mban. Kredencialet e swanctl ndjekin të njëjtën konventë, prandaj një vlerë e zhvendosur midis dy ndërfaqeve e ruan kuptimin vetëm kur parashtesa e saj udhëton me të.

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

Dy detaje në atë bllok marrin më shumë kohë. Shifrat heksadecimal pranojnë të dyja shkrimet, prandaj 0x6b657931 dhe 0x6B657931 janë e njëjta vlerë, por një numër tek karakteresh lexohet gabimisht në heshtje në vend që të refuzohet, gjë që zhvendos çdo bajt pas prerjes. Mbushja Base64 është pjesë e vlerës, prandaj një varg i ngjitur pa shenjat = e tij përfundimtare dekodohet në bajt të tjerë në vend që të dështojë me zë.

Një profil që e ka dekoduar vlerën një herë e ka konvertuar tashmë, prandaj dekodimi përsëri prodhon bajt të tjerë dhe një dështim vërtetimi që lexohet si fjalëkalim i gabuar. Thonjëzat janë drejtimi i sigurt për çdo gjë të paqartë, sepse përmbajtja është fjalë për fjalë edhe kur fillon me një shenjë kodimi.

Nga vjen teksti Base64

Eksportet e profileve dhe portat e furnitorëve shpesh e dorëzojnë çelësin tashmë të koduar, zakonisht në një fushë të dhënash që nuk ishte menduar kurrë për t'u shtypur me dorë. Ose zbërtheni atë vlerë dhe ruani tekstin e dekoduar midis thonjëzave, ose lëreni të koduar me shenjën përpara. Të bësh gjysmën e secilit është ajo që e prish. Të dyja rrugët funksionojnë vetëm nëse e gjithë vlera i mbijeton kopjimit.

Të dy drejtimet janë nga një komandë, dhe ia vlen t'i mbani në tiketë si operacioni i saktë që prodhoi vlerën e ruajtur. Ekzekutojini në këtë rend:

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

Ngjitja e tekstit të koduar sikur të ishte i thjeshtë është gabimi i kushtueshëm. Skedari i hash-on karakteret saktësisht siç janë shkruar, çelësi i prejardhur del rreth një të tretën më i gjatë se ai që llogariti pala tjetër, dhe çdo përpjekje dështon njësoj pa paralajmërim, sepse analizuesi ndoqi rregullin që iu dha.

Konfirmoni cilat bajt përdor në të vërtetë secila palë

Lexoni së pari pamjen e daemonit për lidhjen dhe më pas rezultatin e vërtetimit, në vend që të hamendësoni një shkak nga vargu i gabimit. Krahasimi i gjatësisë së ruajtur është një kontroll i shpejtë mendjeje, sepse teksti i koduar është më i gjatë se bajt që përfaqëson. Pastaj konfirmoni cili rresht identiteti u përputh, sepse një sekret i saktë i ruajtur nën palën e gabuar dështon saktësisht si një i gabuar. Rendi i rreshtave e vendos këtë: përputhja e parë fiton, prandaj një rresht i gjerë %any pranë kryes zëvendëson në heshtje rreshtin specifik që sapo redaktuate.

Ringarkoni në vend që të rinisni kur skedari është i saktë. ipsec rereadsecrets rifreskon kopjen e daemonit IKE, dhe një konfigurim swanctl i ngarkon kredencialet me komandën e vet. Rinisja hedh çdo shoqatë të vendosur dhe shkatërron krahasimin që po përpiqeshit të bënit.

Asnjë prej këtyre kontrolleve nuk kërkon ekspozimin e sekretit. Një gjatësi, një përzgjedhës identiteti dhe një pozicion rreshti shpjegojnë shumicën e dështimeve të këtij lloji përpara se dikush të ketë nevojë për një dump heksadecimal.

Ndryshoni skedarin pa e fshehur rezultatin

Kufizoni skedarin në llogarinë e daemonit dhe mbani sekretet e gjalla jashtë tiketave, bisedave dhe pamjeve të ekranit, sepse një çelës i ngjitur është rrjedhje dhe jo diagnozë. Ai gjithashtu i mbijeton incidentit që e prodhoi.

Testoni nga një klient, konfigurimin e të cilit e kontrolloni ju, konfirmoni që vërtetimi ia del, dhe më pas konfirmoni që tuneli transporton trafik. Një ringarkim që rregullon shtrëngimin e duarve ndërsa rrugëtimi mbetet i prishur është një problem tjetër, dhe bëhet i dukshëm sapo sekreti ndalon së lëvizuri.