0x o 0s? Pag-unawa sa format ng PSK sa ipsec.secrets

Ang isang kliyente ay nagpapatunay gamit ang shared key at tinatanggihan ito ng isa pa, kahit magkapareho ang itsura ng mga character na iyong ipinaste sa magkabilang panig. Malamang pareho silang character; ang pagkakaiba ay kung aling tuntunin ng decoding ang inilalapat ng file sa kanila. Ang string sa loob ng panipi ay kinukuha nang literal, ang token na nagsisimula sa 0x ay binabasa bilang hexadecimal, at ang token na nagsisimula sa 0s ay binabasa bilang Base64. Isa lang sa tatlong ispeling na iyon ang nangangahulugan ng iyong intensyon, kaya ang pagwawasto ay karaniwang isang conversion at hindi isang mas mabuting password.

Ang sintomas ay tumuturo sa encoding, hindi sa mga cipher

Kapag magkaiba ang byte na hawak ng dalawang dulo, nagtatagumpay pa rin ang negosasyon at nabibigo ang patunay pagkatapos. Nag-uulat noon ang log ng pagkabigo sa integridad o HMAC sa halip na pagkakaiba ng algorithm, dahil may napiling proposal at hindi tumugma ang hakbang ng authentication. Hindi kailanman binabanggit ng linyang iyon ang hugis ng secret.

Ang yugto ang palatandaan. Ang pagkabigong dumarating pagkatapos ng napiling proposal ay nangangahulugang nagkasundo ang dalawang panig sa lahat maliban sa key material, samantalang ang «walang napiling proposal» ay kabilang sa patakaran o sa mga cipher suite. Ang pagsusuri ng integridad na nabibigo habang mukhang tama ang password ay ang nakikitang mukha ng pagkakaiba sa encoding.

Isang secret, tatlong paraan ng pagbasa ng file dito

Para sa halagang apat na byte key1, ang hexadecimal at Base64 ay dalawang muling pag-encode ng parehong byte, at ang mga unang character lang ang nagsasabi sa parser kung alin ang hawak nito. Sinusunod ng mga kredensyal ng swanctl ang parehong kombensyon, kaya ang halagang inilipat sa pagitan ng dalawang interface ay pinapanatili ang kahulugan kung ang prefix nito ay sumasama.

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

Dalawang detalye sa bloke na iyon ang kumakain ng pinakamaraming oras. Tumatanggap ang hexadecimal digit ng dalawang kaso, kaya ang 0x6b657931 at 0x6B657931 ay parehong halaga, ngunit ang kakaibang bilang ng character ay tahimik na nababasa nang mali sa halip na tanggihan, na naglilipat sa bawat byte pagkatapos ng hiwa. Bahagi ng halaga ang padding ng Base64, kaya ang string na ipinaste nang walang mga dulong = na tanda nito ay nade-decode sa ibang byte sa halip na mabigong malakas.

Ang profile na minsan nang nag-decode ng halaga ay nakapag-convert na nito, kaya ang muling pag-decode ay gumagawa ng ibang byte at pagkabigo sa authentication na mababasa na parang maling password. Ang mga panipi ang ligtas na direksyon para sa anumang malabo, dahil literal ang nilalaman kahit nagsisimula ito sa marker ng encoding.

Saan nagmumula ang tekstong Base64

Madalas na ibinibigay ng mga profile export at portal ng vendor ang susi na naka-encode na, karaniwang sa isang field ng data na hindi kailanman sinadya para i-type nang manu-mano. Alinman sa buksan ang halagang iyon at itabi ang na-decode na teksto sa loob ng panipi, o hayaang naka-encode ito na may marker sa unahan. Ang gawin ang kalahati ng bawat isa ang siyang sumisira. Gumagana lang ang dalawang landas kung ang buong halaga ay nakaligtas sa pagkopya.

Ang dalawang direksyon ay tig-isang command, at sulit na itabi sa ticket bilang ang eksaktong operasyong gumawa ng naka-imbak na halaga. Patakbuhin ang mga ito sa ganitong pagkakasunod-sunod:

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

Ang pag-paste ng naka-encode na teksto na parang ordinaryo ang mamahaling pagkakamali. Hinahash ng file ang mga character nang eksakto ayon sa nakasulat, ang nagmula na key ay lumalabas na humigit-kumulang isang katlo na mas mahaba kaysa sa kinakalkula ng kapares, at ang bawat pagtatangka ay nabibigo sa parehong paraan nang walang babala, dahil sinunod ng parser ang tuntuning ibinigay dito.

Tiyakin kung aling byte ang aktwal na ginagamit ng bawat kapares

Basahin muna ang pananaw ng daemon sa koneksyon at pagkatapos ang resulta ng authentication, sa halip na hulaan ang sanhi mula sa string ng error. Ang paghahambing ng naka-imbak na haba ay mabilis na pagsusuri ng katinuan, dahil ang naka-encode na teksto ay mas mahaba kaysa sa byte na kinakatawan nito. Pagkatapos ay tiyakin kung aling hilera ng pagkakakilanlan ang tumugma, dahil ang tamang secret na inilagay sa ilalim ng maling kapares ay nabibigo nang eksakto tulad ng mali. Ang pagkakasunod-sunod ng mga hilera ang nagpapasya nito: ang unang tugma ang nananalo, kaya ang malawak na %any na hilera malapit sa itaas ay tahimik na pumapalit sa partikular na hilerang binago mo lang.

I-reload sa halip na i-restart kapag tama na ang file. ipsec rereadsecrets ay nagre-refresh sa kopya ng IKE daemon, at ang setup ng swanctl ay naglo-load ng mga kredensyal sa sarili nitong command. Ang pag-restart ay nagtatapon sa bawat naitatag na asosasyon at sinisira ang paghahambing na sinusubukan mong gawin.

Wala sa mga pagsusuring ito ang nangangailangan ng pagbubunyag ng secret. Ang haba, tagapili ng pagkakakilanlan at posisyon ng hilera ay nagpapaliwanag sa karamihan ng ganitong pagkabigo bago pa may mangailangan ng hex dump.

Baguhin ang file nang hindi itinatago ang resulta

Limitahan ang file sa account ng daemon, at ilayo ang mga buhay na secret sa mga ticket, chat at screenshot, dahil ang naipaste na susi ay pagtagas at hindi diagnosis. Mas matagal din itong nabubuhay kaysa sa insidenteng gumawa nito.

Subukan mula sa isang kliyenteng kontrolado mo ang configuration, tiyakin na nagtatagumpay ang authentication, at pagkatapos ay tiyakin na nagdadala ng trapiko ang tunnel. Ang reload na nag-aayos ng handshake habang sira pa rin ang routing ay ibang problema, at nagiging nakikita ito sa sandaling tumigil sa paggalaw ang secret.