IPsec-voorafgedeelde sleutel: die grepe agter die string wat jy getik het

Twee administrateurs vergelyk die geheim op die skerm, stem saam dat dit ooreenstem, en tog misluk die tonnel se verifikasie. Die string wat hulle vergelyk het, is nie die waarde wat enige van die kante in die sleutelafleiding invoer nie. Tussen die karakters wat jy sien en die grepe wat die protokol hash, is daar ’n veldtjie, ’n tekskodering, ’n redigeerder en ’n knipbord, en enige van die vier kan die invoer verander sonder om die voorkoms daarvan te verander. Vergelyk die grepe, en die verskil kom gewoonlik binne sekondes na vore.

Wat die gateway met die string doen

’n Vooraf-gedeelde sleutel word nie oor die draad gestuur en vergelyk nie. Elke kant voer sy plaaslike kopie in die sleutelafleiding vir die IKE-uitruiling in, en die resulterende verifikasieladings verifieer of nie. Daardie ontwerp beteken die twee kopieë moet grepe-identies wees eerder as visueel soortgelyk, en dit beteken ook dat die fout by die verifikasiefase gerapporteer word eerder as as ’n verkeerde-wagwoord-boodskap.

Die nuttige vraag is dus nooit “lyk hierdie dieselfde nie”, maar “watter presiese reeks grepe hash elke implementering”.

Waar ekstra grepe vandaan kom

’n Aflopende nuwe reël is die klassieke skuldige, en dit versteek hom in die oop sig omdat die meeste redigeerders een onsigbaar byvoeg wanneer ’n lêer gestoor word. ’n Voorste of aflopende spasie wat uit ’n chatvenster geplak is, doen dieselfde ding, en so ook ’n slim aanhalingsteken wat deur ’n woordverwerker vir ’n reguit een vervang is. Nie een van dié verander die visuele vergelyking wat ’n mens doen nie.

Vergelyk met ’n instrument wat grepe eerder as gliewe wys. printf '%s' "$PSK" | xxd | tail -2 druk die stert van die waarde in heksadesimaal, waar ’n rondloper 0a of 20 duidelik is. Doen dit aan beide kante en vergelyk die twee dumps langs mekaar. Doen dit op gegenereerde toetsmateriaal, nie op ’n produksiegeheim wat jy daarna in ’n dopgeskiedenis los nie.

Geënkodeer is nie geënkripteer nie

Konfigurasie-uitvoere dra dikwels die geheim in ’n basiskodering, soms met reëlbreuke elke sestig of ses-en-sewentig karakters en soms met opvulling. As een kant die gedekodeerde grepe verwag en jy plak die geënkodeerde teks, het jy nie ’n ander wagwoord gestuur nie, jy het ’n veel langer een uit drukbare karakters gestuur. Base64 bied glad geen vertroulikheid nie, en dit is ook hoekom ’n geënkodeerde geheim nooit in ’n forum vir ’n tweede mening geplak moet word nie.

Apple se IPSec-woordeboek is ’n nuttige voorbeeld van tipe wat saak maak: dit dokumenteer SharedSecret as data vir die vooraf-gedeelde-geheim-verifikasiemetode in die L2TP- en Cisco IPsec-ladings. Dit is ’n spesifieke eienskap in ’n spesifieke lading, nie ’n algemene teksveld wat jy vir ’n ander protokol kan hergebruik wat toevallig ’n geheim vra nie.

’n Beweerde limiet hoort by een kombinasie

Ou verslae van ’n perk van twee-en-dertig karakters op een Apple-kliënt is werklike verslae oor een kliëntweergawe, protokol en profielvorm. Hulle is nie ’n universele limiet vir elke Apple-platform, elke verskaffer en elke protokol nie. Kontroleer die weergawe, die ladingtipe en die gateway-vereiste saam, en toets dan op ’n goedgekeurde reëling eerder as om uit ’n draadjie af te lei. Skryf die getoetste kombinasie in die veranderingsrekord, want die volgende persoon sal andersins dieselfde draadjie met meer selfvertroue aanhaal as wat dit verdien.

As ’n limiet werklik geld, is die antwoord ’n ondersteunde geloofsbriefontwerp wat daarby pas, nie ’n verkorte weergawe van ’n sterk geheim nie. Om ’n produksiesleutel te verkort om aan ’n geraamde limiet te voldoen, verminder sy sterkte permanent en lewer ’n stelsel op waarvan die dokumentasie nie meer by sy sekuriteit pas nie.

Herstel die voorstelling, nie die sterkte nie

Wanneer verifikasie misluk nadat die voorstelling bevestig is, lees die effektiewe beleid by die verifikasiestadium: watter metode onderhandel word, watter eweknie-identiteit verwag word, en of die gateway by die verbinding pas wat jy dink dit is. Progressief swakker raaiskote is nie diagnose nie, dit is ’n stadige afgradering met ’n ondersteuningskaartjie aangeheg.

As die vereiste geloofsbrief nie aan die organisasie se standaard kan voldoen nie, verander die ontwerp na een wat kan. ’n Gedeelde geheim met genoeg entropie, een keer gegenereer, in ’n bestuurde veld gestoor en nooit gepubliseer nie, is ’n heeltemal goeie antwoord; ’n korter weergawe daarvan is nie.