0x aŭ 0s? Kiel legi la PSK-formaton en ipsec.secrets

Unu kliento aŭtentikigas sin per la komuna ŝlosilo kaj alia malakceptas ĝin, kvankam la signoj, kiujn vi algluis, aspektas samaj ambaŭflanke. Verŝajne temas pri la samaj signoj; la diferenco estas, kiun malĉifran regulon la dosiero aplikas al ili. Signoĉeno en citiloj estas prenata laŭvorte, ĵetono komenciĝanta per 0x estas legata kiel deksesuma, kaj ĵetono komenciĝanta per 0s estas legata kiel Base64. Nur unu el tiuj tri skribmanieroj signifas tion, kion vi celis, do la riparo kutime estas konvertado, ne pli bona pasvorto.

La simptomo montras al kodigo, ne al ĉifroj

Kiam la du finoj tenas malsamajn bitokojn, la intertraktado tamen sukcesas kaj la pruvo malsukcesas poste. La protokolo tiam raportas integrecan aŭ HMAC-malsukceson anstataŭ algoritmo-diskongruon, ĉar propono estis elektita kaj la aŭtentikiga paŝo ne kongruis. Tiu linio neniam mencias la formon de la sekreto.

La stadio estas la indiko. Malsukceso alvenanta post elektita propono signifas, ke ambaŭ flankoj interkonsentis pri ĉio krom la ŝlosila materialo, dum «neniu propono elektita» apartenas al politiko aŭ al ĉifro-aroj. Integreca kontrolo, kiu malsukcesas dum la pasvorto aspektas ĝusta, estas la videbla vizaĝo de kodiga diskongruo.

Unu sekreto, tri manieroj kiel la dosiero povas legi ĝin

Por la kvar-bitoka valoro key1 deksesuma kaj Base64 estas du rekodigoj de la samaj bitokoj, kaj nur la komencaj signoj diras al la analizilo, kiun ĝi tenas. swanctl-legitimaĵoj sekvas la saman konvencion, do valoro translokigita inter la du interfacoj konservas sian signifon nur se ĝia prefikso vojaĝas kun ĝi.

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

Du detaloj en tiu bloko kostas la plej multe da tempo. Deksesumaj ciferoj akceptas ambaŭ literujojn, do 0x6b657931 kaj 0x6B657931 estas la sama valoro, sed nepara nombro da signoj estas silente mislegata anstataŭ malakceptata, kio ŝovas ĉiun bitokon post la tranĉo. Base64-plenigo apartenas al la valoro, do signoĉeno algluita sen siaj finaj = signoj malĉifriĝas al aliaj bitokoj anstataŭ malsukcesi laŭte.

Profilo, kiu malĉifris la valoron unufoje, jam konvertis ĝin, do malĉifro denove produktas aliajn bitokojn kaj aŭtentikigan malsukceson, kiu legiĝas kiel malĝusta pasvorto. Citiloj estas la sekura direkto por io ajn ambigua, ĉar la enhavo estas laŭvorta eĉ kiam ĝi komenciĝas per kodiga markilo.

De kie venas la Base64-teksto

Profil-eksportoj kaj vendistaj portaloj ofte transdonas la ŝlosilon jam koditan, kutime en datuma kampo, kiu neniam estis destinita por permana entajpo. Aŭ malvolvu tiun valoron kaj konservu la malĉifritan tekston en citiloj, aŭ lasu ĝin kodita kun la markilo antaŭe. Fari duonon de ĉiu estas tio, kio rompas ĝin. Ambaŭ vojoj funkcias nur se la tuta valoro postvivas la kopiadon.

Ambaŭ direktoj estas po unu komando, kaj indas konservi ilin en la bileto kiel la precizan operacion, kiu produktis la konservitan valoron. Rulu ilin en ĉi tiu ordo:

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

Alglui koditan tekston kvazaŭ ĝi estus ordinara estas la multekosta eraro. La dosiero haŝas la signojn precize kiel skribite, la derivita ŝlosilo elvenas proksimume trionon pli longa ol tiu, kiun la kunulo komputis, kaj ĉiu provo malsukcesas same sen averto, ĉar la analizilo sekvis la regulon, kiun ĝi ricevis.

Konfirmu, kiujn bitokojn ĉiu kunulo efektive uzas

Unue legu la vidon de la demono pri la konekto kaj poste la aŭtentikigan rezulton, anstataŭ diveni kaŭzon el la erarĉeno. Kompari la konservitan longon estas rapida prudenta kontrolo, ĉar kodita teksto estas pli longa ol la bitokoj, kiujn ĝi reprezentas. Poste konfirmu, kiu identeca vico kongruis, ĉar ĝusta sekreto metita sub la malĝusta kunulo malsukcesas same kiel malĝusta. La ordo de la vicoj decidas tion: la unua kongruo venkas, do larĝa %any-vico proksime al la supro silente anstataŭigas la specifan vicon, kiun vi ĵus redaktis.

Reŝargu anstataŭ restartigi, kiam la dosiero estas ĝusta. ipsec rereadsecrets refreŝigas la kopion de la IKE-demono, kaj swanctl-agordo ŝargas legitimaĵojn per sia propra komando. Restartigo forĵetas ĉiun starigitan asocion kaj detruas la komparadon, kiun vi provis fari.

Neniu el tiuj kontroloj postulas malkaŝi la sekreton. Longo, identeca elektilo kaj vica pozicio klarigas la plej multajn tiajn malsukcesojn antaŭ ol iu bezonas deksesuman elprenaĵon.

Ŝanĝu la dosieron sen kaŝi la rezulton

Limigu la dosieron al la konto de la demono, kaj tenu vivajn sekretojn ekster biletoj, babilejoj kaj ekrankopioj, ĉar algluita ŝlosilo estas liko, ne diagnozo. Ĝi ankaŭ postvivas la incidenton, kiu produktis ĝin.

Testu el kliento, kies agordon vi kontrolas, konfirmu, ke la aŭtentikigo sukcesas, kaj poste konfirmu, ke la tunelo portas trafikon. Reŝargo, kiu riparas la manpremon dum enkursigado restas rompita, estas alia problemo, kaj ĝi videblas tuj kiam la sekreto ĉesas moviĝi.